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Abstract 


We  define  an  interpretation  of  Standard  ML  into  type  theory.  The  interpretation  takes  the 
form  of  a  set  of  elaboration  rules  reminiscent  of  the  static  semantics  given  in  The  Definition 
of  Standard  ML.  In  particularFthe  elaboration  rules  are  given  in  a  relational  styleFexploiting 
indeterminacy  to  avoid  over-commitment  to  specific  implementation  techniques.  Elaboration 
consists  of  identifier  scope  resolutionFtype  checking  and  type  inferenceFexpansion  of  derived 
formsF  pattern  compilationFoverloading  resolutionF  equality  compilationFand  the  coercive 
aspects  of  signature  matching. 

The  underlying  type  theory  is  an  explicitly-typed  A-calculus  with  productFsumFfunctionF 
and  recursive  typesFtogether  with  module  types  derived  from  the  translucent  sum  formalism 
of  Harper  and  Lillibridge.  Programs  of  the  type  theory  are  given  a  type-passing  dynamic 
semantics  compatible  with  constructs  such  as  polymorphic  equality  that  rely  on  type  analysis 
at  run-time. 

This  document  supercedes  the  previous  CMU  CS  technical  reports  CMU-CS-96-136  and 
CMU-CS-96-136R.  The  revision  reflects  our  experience  in  implementing  the  specified  elabo- 
ratorFand  includes  several  essential  corrections  and  simplifications  to  the  presentation. 
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Introduction 


1.1  Overview 

This  document  consists  of  a  type-theoretic  account  of  a  variant  of  (Revised)  Standard  ML 
[MTHM97]rhereafter  referred  to  simply  as  Standard  ML  or  SML.  The  approach  taken  here  is 
to  elaborate  SML  abstract  syntax  (the  external  languagd^ox  EL)  into  an  explicitly-typed  A- 
calculus  (the  internal  languageTor  IL).  The  internal  language  is  designed  to  be  as  simple  and 
orthogonal  as  possible  while  still  being  able  to  represent  the  entire  Standard  ML  language. 

The  translation  is  presented  by  a  set  of  inference  rules  reminiscent  of  the  static  se¬ 
mantics  given  in  The  Definition  of  Standard  MLFwith  the  internal  language  playing  the 
role  of  the  static  semantic  objects  of  The  Definition.  The  translation  rules  typically  define 
the  translation  of  a  phrase  in  terms  of  the  translation  of  its  constituent  phrasesF  subject 
to  context-sensitive  constraints  expressed  by  the  internal  language  type  system.  Context- 
sensitive  formation  constraints  are  expressed  by  type  checking  constraints  on  the  translation. 
Type  propagation  is  controlled  by  a  combination  of  the  translucent  sum  formalism  together 
with  the  representation  of  abstract  types  as  modules  with  opaque  type  components.  The 
internal  language  ensures  that  abstraction  is  respectedFandFmoreoverFprovides  the  requisite 
association  of  the  abstract  type  to  its  representation  at  run-time. 

We  believe  that  looking  at  Standard  ML  language  features  in  terms  of  how  they  translate 
into  type  theory  clarifies  a  number  of  issues  in  the  design  of  SML.  For  exampleFthe  notion 
of  “type  generativity”  is  replaced  by  explicit  control  of  type  propagation. 

The  internal  language  may  be  shared  among  many  different  language  descriptions  given 
in  the  style  presented  here.  In  particularFwe  envision  the  possibility  of  using  the  IL  given 
here  (with  very  minor  modifications)  for  SchemeFCaml  Special  LightFor  Haskell.  A  more 
long-term  goal  would  be  to  see  what  changes  would  be  needed — especially  with  regards  to 
object-oriented  features — in  order  to  handle  Java  or  Modula-3. 

The  elaboration  has  application  to  language  implementation  as  wellFas  it  may  be  viewed 
as  a  reference  implementation  of  a  front-end  for  an  SML  compiler.  In  particularFwe  are 
using  this  translation  as  a  guide  to  our  re-implementation  of  the  TIL/ML  compiler  [HM95F 
Mor95FTar96FTMC'*'96].  Compilers  for  other  languages  defined  by  interpretation  into  the 
internal  language  could  share  the  back  end  of  the  TIL/ML  compiler;  only  a  front-end  need 
be  written  for  each  specific  language. 

There  are  some  disadvantages  to  our  approach.  The  translation  of  some  SML  language 
features  is  quite  complex.  To  some  extent  this  is  a  direct  reflection  of  the  intrinsic  complex¬ 
ity  of  mechanisms  such  as  datatype  definitions  (which  introduce  several  mutually  recursive 
abstract  typesFeach  a  multinary  sum  of  multinary  product  types)  and  polymorphicFrecur- 
sive  function  bindings.  However Fensuring  that  the  invariants  of  our  encodings  are  respected 
everywhere  in  the  document  can  be  tedious  and  error-prone. 

FurthermoreFunderstanding  the  elaboration  requires  understanding  the  internal  language 
as  wellFthough  this  may  be  mitigated  if  the  same  internal  language  can  be  used  for  several 
different  external  languages. 

The  type-theoretic  interpretation  of  Standard  ML  is  divided  into  three  main  parts. 
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Type  Structure  of  the  Internal  Language.  The  internal  language  is  an  explicitly- typed 
A-calculusTwith  a  second-class  modules  system. 

The  core  of  the  internal  language  is  based  on  the  XML  and  calculi  [HMOSFHMMQO]. 
The  constructors  of  kind  Q  (where  is  the  kind  of  types)  include  partial  and  total  function 
typesT  record  typesT  sum  typesF  reference  typesT  recursive  typesT  and  a  single  extensible 
sum.  AdditionallyTthe  constructors  are  extended  with  (restricted)  tuples  of  constructors  and 
functions  at  the  constructor  level.  Note  that  there  are  no  polymorphic  types  (polytypes)  in 
our  system. 

The  modules  system  is  based  on  the  translucent  sum  or  manifest  type  modules  cal¬ 
culi  [HL94rLer94].  In  addition  to  translucent  signaturesTwe  have  total  and  partial  functor 
signatures.  Our  subtyping  relation  on  signatures  involves  only  forgetting  of  type  definitions 
and  totalityFand  not  dropping  or  reordering  components.  This  means  that  subtyping  has 
no  run-time  effect. 

The  two  levels  are  connected  by  the  ability  to  define  modules  local  to  a  core  expression. 

Dynamic  Semantics  of  the  Internal  Language.  The  dynamic  semantics  is  essentially 
a  contextual  semantics  [WF91].  The  handling  of  references  and  exceptions  is  similar  to 
Harper’s  account  of  polymorphic  references  [Har93]. 

Elaboration.  The  translation  is  defined  by  a  series  of  translation  judgments  of  the  general 
form 

F  h  EL-phrase  ^  IL-phrase  ;  IL-classifier 

where  F  is  an  internal-language  context  extended  with  information  mapping  EL  identifiers 
to  IL  variables. 

1.2  Notes  on  Implementat^ion 

This  document  is  intended  as  an  experiment  in  formally  specifying  the  first  stage  of  the  TIL 
compilerFand  additionally  to  see  if  this  generates  a  plausible  definition  for  a  language.  We 
are  not  advocating  that  a  compiler  should  generate  exactly  the  IL  code  given  hereFnor  even 
that  the  internal  language  of  the  compiler  should  be  exactly  the  IL  we  present.  HoweverF 
any  implementation  of  an  elaborator  should  be  essentially  equivalent  to  what  we  presentF 
and  we  suggest  the  compiler’s  internal  language  should  be  definable  in  terms  of  the  IL  we 
present  here.  Differences  we  would  expect  in  an  actual  implementation  include: 

•  The  internal  language  is  likely  be  extended  to  make  our  derived  forms  into  primitivesF 
possibly  along  with  other  definable  forms. 

•  A  compiler  is  likely  to  use  a  much  more  complicated  pattern  compilerFgenerating  much 
more  efficient  pattern-matching  code  (in  particularFmaking  better  use  case). 

•  Clausal  function  definitions  would  not  be  sequenced  through  uses  of  the  exception 
mechanism. 
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•  A  compiler  is  likely  to  use  a  much  more  efficient  implementation  of  elaboration  contextsF 
avoiding  the  the  sequential  search  which  we  have  formalized. 

•  Equality  functions  would  be  cachedF  so  that  multiple  equality  tests  for  values  of  the 
same  type  would  not  generate  multiple  equality  functions. 

•  In  order  to  achieve  SML’s  typing  behaviorFlocally-defined  types  at  the  module  level  are 
hidden  through  renaming  rather  than  through  use  of  internal-language  local  bindings. 
For  simplicityFall  module-level  local  definitions  (including  values)  are  translated  in  this 
fashionF though  this  is  not  requiredFand  could  cause  wasted  space  at  run-time.  An 
implementation  would  use  a  more  sophisticated  criterion  for  which  local  bindings  to 
rename. 
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1.3  Major  Differences  from  Standard  ML 

1.3.1  Value  Restriction 

The  value  restriction  used  in  this  translation  is  different  than  that  specified  in  SML. 

•  We  treat 

val  (rec)  pat^  =  expr-^  and  . . .  and  pat^  =  expr^^ 
as  a  derived  form  for 

val  (rec)  {pat^ ,  . ,patj^)  =  {expr^ ,  . . .  ,  expr^) . 

•  When  V  is  a  valueFwe  treat  the  binding  val  h:  :t  =  v  as  completely  equivalent  to 
val  h  =  hd  V  and  val  t  =  tl  v.  Since  in  the  latter  cases  h  and  t  will  not  be  gen¬ 
eralized  (hd  and  tl  may  raise  exceptions !)rh  and  t  are  not  made  polymorphic  in  the 
former  case. 

The  translation  allows  variables  in  a  val  binding  to  be  generalized  if  the  translations 
of  the  bindings  are  “valuable.”  At  the  external  language  levelTthis  is  equivalent  to  the 
right-hand  side  being  a  valueFand  the  variable  not  be  in  the  argument  of  a  constructor 
patternFunless  the  constructor  in  for  a  single-constructor  datatype.  Note  that  tuple- 
patterns  pose  no  problemFsince  projection  is  a  total  function. 

This  corresponds  to  the  notion  of  “polymorphism  as  substitutionF  in  which 

let  val  id=expr  in  expr'  end 

is  considered  equivalent  to  {expr / id] expr'  when  expr  is  a  value. 

Because  of  this  differenceFa  few  variables  that  would  have  been  polymorphic  according 
to  the  SML  specification  will  not  be  generalized  in  this  treatment. 

1.3.2  Abstype 

We  do  not  consider  abstype  declarations  in  this  document  because  abstract  data  types 
can  be  easily  created  using  the  SML  module  system  instead.  There  would  be  no  technical 
difficulties  in  including  abstypeFif  desired. 

1.3.3  Local  and  Higher-Order  Functors 

Our  external  language  permits  structure  and  functor  declarations  within  a  let  or  local 
declarationsFand  also  within  structure  and  functor  declarations;  this  is  a  reflection  of  the 
fact  that  the  internal  language  has  local  and  higher-order  modules. 

These  higher-order  modules  are  based  on  the  translucent  sum  formalism  [HL94].  As 
this  is  compatible  with  first-class  modules  (which  are  not  included  in  this  definition) Four 
higher-order  functors  propagate  less  type-sharing  information  than  those  in  the  system  of 
MacQueen  and  Tofte  [MT94].  Finding  a  clean  type-theoretic  description  of  this  latter  system 
is  the  subject  of  current  research. 
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1.3.4  Top-level 

Since  we  allow  locally-defined  modules  in  our  external  languageFit  suffices  to  consider  pro¬ 
grams  to  be  closed  expressions  of  type  onsrwhere  ans  is  a  fixed  base  type  of  answers.  We 
do  not  explicitly  consider  the  translation  of  SML  top-level  declarations. 

Note  that  this  does  not  require  an  implementation  to  accept  only  complete  programs  of 
some  fixed  type.  For  exampleFa  batch  compiler  may  expect  a  sequence  of  structureFfunctorF 
and  signature  bindings  (SML  top-level  declarationsF  possibly  separately  compiled) F  which 
are  then  “logically”  treated  as  a  sequence  of  declarations  in  a  wrapper  generated  by  the 
compiler.  For  a  UNIX  systemFfor  exampleFthe  wrapper  might  be  along  the  lines  of: 

let  •••  in  0  end  handle  _  =>  ~1 

where  ans  is  chosen  to  be  the  type  int  and  a  program  returns  either  0  for  normal  termination 
or  ~1  for  an  uncaught  exception. 

To  enable  this  interpretationFwe  view  signature  declarations  as  simple  “macrosF  defin¬ 
ing  abbreviations  for  signatures.  The  translation  assumes  abbreviations  have  previously  been 
expanded  out  in  the  program  body. 


1.4  Major  Technical  Differences  from  Version  2 

1.4.1  Internal  Language 

Some  minor  changes  have  been  made  to  the  internal  languageFfor  purposes  of  efficient  im¬ 
plementation  (e.g.Fthe  unbundling  of  mutual  recursion  and  projection  operations  at  the 
constructor  and  expression  levels)F  or  for  the  purposes  of  a  cleaner  elaboration  or  inter¬ 
nal  language  (e.g.Fthe  generalization  of  the  kind  structureFand  the  replacement  of  partial 
destructuring  operations  with  total  versions  at  the  expression  level). 

1.4.2  Datatypes 

The  rule  for  datatypes  has  been  simplified;  additionally  the  internal  language  has  been  ex¬ 
tended  to  allow  all  valid  SML  datatypes  to  elaborate.  HoweverFcertain  datatypes  that  SML 
defines  as  admitting  equality  would  require  polymorphic  recursion  to  implement  this  equality 
function.  Since  our  language  does  not  currently  admit  polymorphic  recursion  (which  would 
correspond  to  recursive  functors)  these  datatypes  do  not  admit  equality  in  our  formulation. 

1.4.3  Generativity 

A  technical  problem  with  our  presentation  caused  us  to  reject  some  legal  Standard  ML 
programsF  because  of  type  information  was  not  tracked  properly.  This  problem  involved 
abstract  types  defined  in  anonymous  structure  expressionsFdefined  locally  in  let  or  local 
at  the  module  levelFor  hidden  by  SML’s  transparent  ascription  (strexp  :  sigexp).  This 
has  been  corrected  by: 

1.  Restricting  the  EL  to  named  form  at  the  module  levelFfollowing  Leroy  [Ler96].  This 
can  always  be  achieved  by  a  simple  prepass  over  the  program.  (The  grammar  in 
Section  5  shows  what  we  mean  by  named  form.) 
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2.  In  the  case  that  let  and  local  module  forms  define  abstract  types  locallyFin  the 
translation  we  augment  the  bodies  of  these  forms  with  extra  “hidden”  fields  containing 
these  abstract  types.  In  conjunction  with  the  restriction  to  named  formlthis  has  the 
effect  of  causing  types  concealed  by  transparent  ascription  to  be  renamed  rather  than 
dropped  entirely.^ 

Although  the  internal  language  module  system  presented  here  does  not  have  most-specific 
signatures  in  generalFwe  also  ensure  that  all  modules  generated  by  the  elaborator  do  have 
most-specific  signatures.  This  means  that  the  elaborator  never  requires  “guessing”  of  signa¬ 
tures  for  modules  such  as  functor  applications. 

1.4.4  Subtyping 

We  have  dropped  the  implicit  subsumption  between  total  and  partial  function  types;  every 
expression  now  has  a  unique  most-specific  types  up  to  equivalence.  Unfortunately  this  means 
datatype  and  exception  constructors  must  now  be  handled  specially  when  used  as  function 
values.  HoweverFa  full  subtyping  relation  would  seem  to  be  overkill — at  least  until  features 
such  as  objects  are  added  to  the  internal  language. 

1.4.5  Syntactic  concatenation 

Rather  than  using  the  starred  structure  convention  for  general  concatenation  of  modulesFwe 
use  a  syntactic  concatenation  of  structure  field  bindings.  This  includes  renaming  to  prevent 
ill-formed  constructions  where  two  fields  share  the  same  label. 


^For  simplicity,  the  rules  essentially  augment  the  bodies  of  let  and  local  with  all  the  locally-defined 
quantities.  Most  of  these — including  all  value  components  and  transparent  type  components — are  obviously 
unnecessary  and  undesirable  in  an  actual  implementation. 
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2  Internal  Language  Abstract  Syntax 

2.1  Constructors  and  Kinds 


con  :;=  var 

I  Int  I  Float  I  Char  |  •  •  • 

I  {rdecs} 

I  con  Ref 
I  con-^con' 

I  con-^con' 

I  Tagged 
I  con  Tag 

I  '^(lab)  {labit-^coni, . . . ,  labn^conn) 

I  modv-lab 
I  Xvariknd.con 
I  n  con 
I  con  con' 

I  {lab\  —  coni, . . .  ,labn=conn} 

I  '^lab  C'OTl 


type  variables 
base  types 
record  type 
reference  type 
partial  function  type 
total  function  type 
extensible  sum  type 
exception-tag  type 
(labelled)  sum  type 
module  projection 

constructor-level  nonrecursive  function 
constructor-level  fixpoint 
constructor  application 
records  of  constructors 
record  projection 


rdecs  • 

I  rdecs,  rdec 
rdec  ::=  lab:con 


empty 
sequence 
record  field  type 


knd  ::=  Q 

I  {labi'.kndi, . . .  ,labn:kndn} 
I  knd=^knd' 


kind  of  types 
constructor  tuple  kinds 
constructor  function  kinds 


Figure  1:  Constructors  and  Kinds 
The  syntax  (•  •  •)  denotes  a  phrase  which  may  optionally  appear. 
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2.2  Expressions 


exp  ::=  scon 

constants 

1  var 

variables 

1  loc 

memory  locations 

tag 

exception  tags 

1  flxfbnds  end 

mutually-recursive  functions 

1  exp  exp' 

application 

1  {rbnds} 

record  expression 

1  T^lab  exp 

record  projection 

1  handle  exp  with  exp' 

handle  exception 

1  raise'^""  exp 

raise  exception 

1  ref“"exp 

allocate  new  ref  cell 

1  get  exp 

dereference 

1  set  {exp,  exp') 

assignment 

roir^exp 

coerce  into  p,  type 

1  unroll  exp 

coerce  from  p  type 

1  d  exp 

coerce  from  partial  to  total  function 

1  injiaTea:^ 

injection  into  sum 

1 

total  projection  from  sum 

1  case'^®"  exp  of  expi, . ,  exp^  end 

sum  case  analysis 

1  new_tag[con] 

extend  type  Tagged 

1  tag(ea!'p,  exp) 

injection  into  type  Tagged 

1  iftagof  exp  is  exp'  then  exp"  else  exp'" 

exception  tag  case  analysis 

1  mod. lab 

module  projection 

1  exp.y—\n^exp2,  exp-^  Float^a?P2)  ■  •  ■ 

equalities  at  base  types 

rbnds  • 

empty 

1  rbnds,  rbnd 

sequence 

rbnd  ::=  lab=exp 

record  field  binding 

fbnds  ::=  • 

empty 

1  fbnds,  fbnd 

sequence 

fbnd  ::=  var' {var: con): con' exp 

function  binding 

labs  ::=  lab  \  labs. lab 

sequence  of  labels 

path  ::=  var  \  var. labs 

path  (qualified  variable) 

Figure  2:  Expressions 
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2.3  Modules  and  Signatures 


mod 

var 

module  variable 

1 

[sbnds] 

structure 

1 

\var:sig.mod 

functor 

1 

mod  mod' 

functor  application 

1 

mod.  lab 

projection  from  structure 

1 

mod:  sig 

signature  ascription 

sbnds 

■ 

structure  field  bindings 

1 

sbnds,  sbnd 

sbnd  ::= 

labt>bnd 

bnd  ::= 

var = con 

constructor  binding 

var = exp 

expression  binding 

var=mod 

module  binding 

sig  :;= 

[sdecs] 

structure  signature 

{var:  sig)  ^  sig' 

partial  functor  signature 

{var :  sig)— ^  sig' 

total  functor  signature 

sdecs  ::= 

sdecs,  sdec 

structure  field  declarations 

sdec  ::= 

■■  lab>dec 

decs  ::= 

1  decs,  dec 

declaration  lists 

dec  ::= 

var:  con 

expression  variable  declaration 

1  var: sig 

module  variable  declaration 

[  var:knd 

opaque  type  declaration 

1  var:knd=con 

transparent  type  declaration 

1  loc'.con 

typed  locations 

1  tag: con 

typed  exception  tag 

Figure  3:  Modules  and  Signatures 


2.4  Useful  Abbreviations  and  Notation 

•  For  readabilityFwe  often  elide  the  internal  names  (war’s)  when  writing  out  sbnds  (and 
sdecs).  In  all  cases  it  should  be  immediately  obvious  how  to  consistently  restore  these 
with  fresh  variables. 

•  We  use  sig-^sig'  and  sig-^sig'  to  abbreviate  {var:sig)-^sig'  and  {var:sig)-^sig'  respec- 
tivelyFwhere  var  is  not  free  in  sig' . 

•  Many  grammatical  classes  {lahsVdecsTrdecsVrhndsTfbndsTsdecsTsbndsT etc?)  specify 
lists  of  elements.  For  each  of  these  classes  we  define  a  binary  append  operationFwritten 
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with  a  comma.  For  exampleFwe  define 


decs, ■  :=  decs 

decs,  [decs' ,  dec')  :=  (decs,  decs'),  dec' 


with  analogous  definitions  for  all  the  other  classes  listed  above. 

•  It  is  useful  to  define  the  following  very  general  syntactic  categories  of  program  phrases 
and  program  phrase  classifiers: 


phrase  ::= 


exp 

class  ::=  con 

mod 

1  sig 

con 

1  knd 

•  The  notation  {phrase /var}phrase'  denotes  the  capture-free  substitution  of  phrase  for 
free  occurrences  of  var  within  phrase'. 

•  For  consisionFwe  often  abbreviate  structure  bindings  labt>var=phrase  as  lab=phraseT 
(and  similarly  signature  bindings  lab\>var: class  as  lab: class)  when  the  local  name  is 
not  used.  In  all  cases  it  should  be  obvious  how  to  consistently  insert  fresh  variables  to 
correct  these  omissions. 

•  We  occasionally  use  the  abbreviation  as  shorthand  for  phrase^,  •  •  • ,  phrase.^ 

(where  the  phrases  are  comma-separated). 

•  The  syntactic  values  of  the  language  are  defined  in  Figure  4.  We  view  each  class  of 
syntactic  values  (clasSy)  as  subsets  of  the  corresponding  class  in  the  abstract  syntax 
(class). 
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expv  " 


rbndsy 

rbndy  :: 
val  :: 


scon 

mody  :  := 

path 

loc 

1 

[sbndsy] 

tag 

1 

Xvar-.sig.mod 

path 

{rbndSy} 

bndy  ::= 

var=expy 

fix  fbnds  end 

1 

var=mody 

TT-^f  lx  finds  end 

1 

var=  con 

inj^T  expy 
tag(expv,  expy) 

sbndsy 

roll'^®"  expy 

1 

sbndSy,  sbndy 

d  expy 

sbndy 

lab'.bndy 

rbndSy,  rbndy 
lab=expy 

expy 

mody 

con 

Figure  4: 

IL  values 
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2.5  Bindings  and  Scope 

We  define  the  functions  BV(-)  and  dom(-)  for  various  bindingshdeclarationsFand  lists  thereof: 


Function 

Definition 

BV(dec) 

BY  {var'.con)  =  var 

BY  {var-.knd)  =  var 

BY  {var  :knd= con)  =  var 

BY  {var:  sig)  =  var 

BY  {loc:  con)  =  loc 

BY  {tag:  con)  =  tag 

BV(decs) 

BY{deci,---,deCn)  =  {BV(deci),  •  •  • ,  BV(dec„)} 

BY (sdecs) 

BY {labi>deci,  •  •  • ,  labn>deCn)  =  {BV(deci),  ■  •  •  ,BV(deCn)} 

BY{bnd) 

BY  {var = exp)  =  var 

BY  {var=con)  =  var 

BY  {var=mod)  =  var 

BY{sbnds) 

BY {labi>bndi,  •  •  • ,  labn>bndn)  =  {BY {bndfi),  •  •  • ,  BY {bndn)} 

dom(5dec5) 

dom{labi>deci,  •  •  ■ ,  labjpdecn)  =  {lab\,  •  •  • ,  labn} 

dom(r’decs) 

dom{labi:coni,  •  •  • ,  labn-conn)  =  {/a&i,  •  ■  • , 
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The  scopes  of  bound  variables  are  given  by  the  following  table; 


Binding  Phrase 

Bound  Vars 

Scope 

fix fbnds,  var'(var:con):expi-^,fbnds' end 

var' 

entire  phrase 

var 

exp 

\var\knd.con 

var 

con 

sbnd,  sbnds 

BY(sbnd) 

sbnds 

Xvar:sig.mod 

var 

mod 

sdec,  sdecs 

BY{sdec) 

sdecs 

var:sig^sig' 

var 

sig' 

var-.sig—i’Sig' 

var 

sig' 

We  follow  standard  practice  and  identify  all  phrases  which  differ  only  with  respect  to 
bound  variablesFlocationsFand  exception  names.  We  use  the  notation  FV (phrase)  to  denote 
the  set  of  free  variables  in  phrase.  A  phrase  is  said  to  be  closed  if  it  has  no  free  variables 
(though  it  may  contain  free  locations  or  tags) . 
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3  Static  Semantics 

3.1  Introduction 

In  this  section  we  define  the  well-formedness  and  typing  judgments  for  the  internal  language. 

Points  of  interest  include: 

•  There  are  no  metatsyntactic  “semantic  objects”  in  the  sense  of  the  Definition. 

•  The  rules  are  explicitly  formulated  so  that  a  judgment  holds  only  if  its  constituents 
(declaration  listsPetc.)  are  well-formed. 

•  The  valuable  expressions  always  evaluate  to  a  value  without  side-effectsP  referencing 
the  storePor  raising  exceptions.  Similar lyP valuable  modules  evaluate  without  side- 
effectsP referencing  the  storePor  raising  exceptions.  The  purpose  of  distinguishing 
total  and  partial  functionsPas  well  as  total  and  partial  functorsPis  to  specify  which 
function/functor  applications  are  valuable. 

3.2  Notation 

•  Within  the  static  semanticsP optional  elements  are  enclosed  by  single  brackets  (•••). 
Within  a  single  rulePeither  all  such  optional  elements  must  occurPor  none. 
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3.3  Judgment  Forms 


Section 

Judgment... 

Meaning... 

3.4.1 

h  decs  ok 
decs  h  dec  ok 

decs  is  well-formed 
dec  is  well-formed 

3.4.2 

decs  h  bnd  :  dec 

bnd  has  declaration  dec 

3.4.3 

decs  h  knd  :  Kind 

knd  is  well-formed 

3.4.4 

decs  h  con  :  knd 

con  has  kind  knd 

3.4.5 

decs  h  con  =  con'  :  knd 

constructor  equivalence  at  kind  knd 

3.4.6 

decs  h  exp  :  con 

exp  has  type  con 

3.4.7 

decs  h  sdecs  ok 
decs  h  sig  :  Sig 

sdecs  is  well-formed 
sig  is  well-formed 

3.4.8 

decs  h  sdecs  <  sdecs' 
decs  h  sig  <  sig'  :  Sig 

component-wise  subtyping 
signature  subtyping 

3.4.9 

decs  h  sdecs  =  sdecs' 
decs  h  sig  =  sig'  :  Sig 

component-wise  equivalence 
signature  equivalence 

3.4.10 

decs  h  sbnds  :  sdecs 
decs  h  mod  :  sig 

sbnds  has  declaration  list  sdecs 
mod  has  signature  sig 

3.4.11 

decs  h  exp  4-  con 
decs  h  mod  4-  sig 
decs  h  exp  t 
decs  h  sbnds  1 
decs  h  mod  1 

exp  is  valuable  with  type  con 
mod  is  valuable  with  signature  sig 
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3.4  Inference  Rules 

3.4.1  Well-formed  Declarations 


h  •  ok 

decs  h  dec  ok 
h  decs,  dec  ok 


decs  I-  knd  :  Kind  var  ^  BY  {decs) 
decs  h  vav.knd  ok 

decs  h  con  ;  knd  var  ^  BV(decs) 
decs  h  var:knd=con  ok 

decs  h  con  :  Q  var  ^  BY (decs) 
decs  h  var:con  ok 

decs  f-  sig  :  Sig  var  ^  BV(c?ecs) 
decs  h  var-.sig  ok 

decs  f-  con  =  con'  Ref  :  17  loc  ^  BY  {decs) 
decs  h  loc'.con  ok 

decs  h  con  =  con' Tag  :  ft  tag  ^  BV(c?ecs) 
decs  h  tag:  con  ok 


h  decs  ok 


decs  h  dec  ok 


3.4.2  Well-formed  Bindings 


decs  h  con  :  knd 
decs  h  var=con  :  var:knd 

decs  h  con  =  con'  :  knd 
decs  h  var=con  :  var:knd—con' 

decs  h  exp  :  con 
decs  h  var— exp  :  var:con 

decs  h  mod  :  sig'  decs  h  sig'  <  sig  :  Sig 
decs  h  var=mod  :  var: sig 


decs  h  bnd 


3.4.3  Well-formed  Kinds 


decs  h  knd  :  Kind 


decs  h  f2 :  Kind 

labi,. . .,  lO'bn  distinct  n  >  0 

(13) 

(14) 

decs  h  {labi'.kndi, . 

. . ,  labn'.kndn)  '■  Kind 

decs  h  knd  :  Kind 

decs  h  knd'  :  Kind 

(15) 

decs  h  knd=>knd'  :  Kind 

3.4.4  Well-formed  Constructors 


h  decs  ok 

decs  =  decs',  var:knd{=con),  decs" 
decs  h  var  ;  knd 


decs  h  con  :  knd 


(16) 


decs  h  Tagged  :  Q 

decs  h  con  :  Q, 
decs  \-  con  Ref  :  Q, 

decs  h  con  :  Q 
decs  h  con  Tag  : 

decs  h  con  :  Q  decs  h  con'  :  O 
decs  h  con-^con'  : 

decs  h  con  :  Q  decs  h  con' : 
decs  h  con^con'  :  Q, 

labi,. . labn  distinct 
decs  h  coni  ^  ■  decs  h  con„  :  Q, 

decs  h  {labi'.coni, . . . ,  labn'-conn}  ■  ^ 

{i  e  l..n) 

labi, labn  distinct 
decs  h  coni  :  •  •  •  decs  h  conn  • 

decs  h  T,(iabi)  {labiy-^coni, labn'-^conn)  '■  O 

labi, ...  ,lab  n  distinct  n>0 
decs  h  coni  :  kndi  •  ■  •  decs  h  con„  :  kndn 
decs  f-  {Za6i=coni, . . . ,  labi=conn}  ■  {labi.kndi, . ..,  labi.kndn} 


(17) 

(18) 

(19) 

(20) 
(21) 

(22) 

(23) 

(24) 


19 


i  G  l..n 


decs  h  con  :  {labi.knd\, . . . ,  labn’kndn} 
decs  h  TTiabi  con  :  kndi 

(25) 

decs,  var'.knd  h  con  :  knd' 
decs  h  Xvav.knd.con  :  knd=^knd' 

(26) 

decs  h  con  :  knd=^knd 
decs  h  /z  con  :  knd 

(27) 

decs  h  con  :  knd'^knd  decs  h  con'  :  knd' 

decs  h  con  con'  :  knd 

(28) 

decs  h  mody  :  [sdecs,  lab>var:knd,  sdecs'] 
decs  h  mody. lab  :  knd 

(29) 

3.4.5  Constructor  Equivalence 

decs  h  con  =  con'  :  knd 

h  decs  ok 

decs  =  decs',  var:knd=con,  decs" 
decs  h  var  =  con  :  knd 

Rule  30:  The  well-formedness  judgment  h  decs  ok  guarantees  that  FV(con)  nBV(decs")  =  0. 


decs  h  mody  :  [sdecs,  lab:knd=con,  sdecs'] 
BV(s(iecs)  n  FV(con)  =  0 
decs  h  mody. lab  =  con  :  knd 


Rule  31:  The  projection  must  yield  a  valid  constructor  with  respect  to  the  ambient  context, 
decs.  This  can  always  be  arranged  through  use  of  the  self  rules  (Rules  101  and  102). 


decs  h  coni  =  con2  ■  decs  h  con^  =  con^  :  ^ 

decs  h  coni—^con[  =  con2-^con'2  '■  O 

decs  h  coni  =  con2  '.  Cl  decs  h  con'i  =  con2  :  Cl 
decs  h  coni—¥con[  =  con2— >-con2  :  Cl 

decs  h  con  =  con'  : 
decs  h  con  Ref  =  con'  Ref  : 

decs  h  con  =  con' :  Cl 
decs  h  con  Tag  =  con'  Tag  :  Cl 

labi,...,  labn  distinct 
Vz  G  l..n  :  decs  h  con*  =  con^  :  Cl 
decs  h  {labi.coni,  ,  labn-conn)  =  {ia6i:con'i,  •  •  • ,  labn.con'.^}  :  Cl 


(32) 

(33) 

(34) 

(35) 

(36) 
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Rule  36:  To  be  equivalent,  two  IL  record  types  must  have  equivalent  components  with  the  same 
labels  in  the  same  order. 


i  G  l..n 

decs  f-  con  =  con'  :  {labi.kndi, . . . ,  labn'kndn} 
decs  h  TTiabi  con  =  con'  :  kndt 

i  G  l..n 

decs  h  con  =  {labi.coni, . . . ,  labn-conn}  :  {labi.kndi, . labn'-kndn} 
decs  h  TTiabi 

dec5  h  con  =  con' :  knd=^knd 
decs  h  con  =  fi  con'  :  knd 

{i  G  l..n) 

(iec5  h  coni  =  con'^  :  •  decs  h  con„  =  con^  :  Q 

decs  h  T,(iabi)  {labi\-^coni, . . . ,  labn^conn)  = 

S<ia6i>  [labi^con'^i . . . ,  labn^con'^)  :  O 

c?ec5  h  coni  =  con2  :  knd'=^knd 
decs  f-  con'i  =  con^  :  knd' 
decs  h  coni  con2  =  con'i  con^  :  knd 

decs,  vav.knd'  h  con  :  knd  decs  h  con  ;  Aind' 
decs  h  {\var:knd' .con)  con'  =  {con'/nar}con  :  A;nd 

decs  h  con  :  knd 
decs  h  con  =  con  :  knd 

decs  h  con'  =  con  :  knd 
decs  h  con  =  con'  :  knd 

decs  h  con  =  con'  :  knd 
decs  h  con'  =  con"  :  knd 
decs  h  con  =  con"  :  knd 


(37) 

(38) 

(39) 

(40) 

(41) 

(42) 

(43) 

(44) 

(45) 


3.4.6  Well-formed  Expressions 


decs  h  exp  :  con 

h  decs  ok 

decs  =  decs',  vav.con,  decs" 

(46) 

decs  f-  var  :  con 

h  decs  ok 

decs  =  decs',  loc.con,  decs" 

(47) 

decs  h  loc  :  con 
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h  decs  ok 

decs  =  decs',  tag:  con,  decs" 


(48) 


decs  h  tag  :  con 

decs  h  exp  :  con' con  decs  h  exp'  :  con' 
decs  h  exp  exp' :  con 

decs  h  exp  :  con'— ^ con  decs  h  exp'  :  con' 

decs  h  exp  exp'  :  con 


(49) 

(50) 


\/i  G  l..n  :  decs,  {var'j:conj^con'j)‘j^i,  varfconi  h  exp^  :  con' 
Rule  52  does  not  apply. 

decs  h  fix  (uar-(uarj:conj):con^i-)-ea:pJ"_i  end  : 
{V.coni—^con']^, . . . ,  n:conn-^con'^} 

var'  ^  FV  exp 
decs,  var: con  h  exp  4-  con' 

decs  \-  f\xvar'{var:con):con'i-^exp  end  :  {l:con—>con'} 


(51) 


(62) 


labi,  -  ■  ■ ,  labn  distinct 

decs  h  expi  :  coni  •  •  ■  decs  h  exp^,  :  conn 
decs  h  {labi=expi,  ••• ,  /a6„=exp„}  :  {labi.coni,  ■■■ ,  labn-conn} 

Rule  53:  For  the  record  bindings  to  be  well-typed  with  respect  to  the  declarations,  they  must 
have  the  same  labels  in  the  same  order  (with  no  duplicate  labels)  and  components  must  be 
well-typed  elementwise. 


decs  h  exp  :  {rdecs,  lab: con,  rdecs'} 
decs  h  TViab  exp  :  con 

(54) 

decs  h  exp  :  con  decs  h  exp'  :  Tagged— ^  con 

decs  h  handle  ea;p  with  exp'  :  con 

(65) 

decs  h  exp  :  Tagged  decs  h  con  : 

decs  h  raise^'*  exp  :  con 

(56) 

decs  h  con  :  0 

(57) 

decs  h  new_tag[con]  :  con  Tag 

decs  f-  exp  :  con 
decs  h  ref*^""  exp  :  con  Ref 

(58) 

decs  h  exp  :  con  Ref 
decs  h  get  exp  :  con 

(69) 

decs  h  exp  :  con  Ref 
decs  h  exp'  :  con 
decs  f-  set  {exp,  exp')  :  Unit 

(60) 
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(61) 


decs  h  con  =  (jriab  (a*  con'))  {con")  : 
decs  h  exp  :  {■Kiab  {con'  {p  con')))  {con") 
decs  h  roir°"  exp  :  con 

decs  h  con  =  (tt/oj,  {p  con'))  {con")  : 
decs  h  e2;p  :  con 

decs  h  unroll  ea;^) ;  {iriab  {con'  {p  con')))  {con") 

decs  h  exp  :  con— y  con' 
decs  h  d  exp  :  con^con' 


i  G  l..n 

con  —  T^iabi  {lo,bp — ^conx, . . . ,  lobn^ — ycon^i) 
decs  h  exp  :  coni 
decs  h  exp  :  con 


i  G  l..n 

decs  h  exp  :  E^afe.  (^a6ii-4coni, . . . ,  labn^conn) 

,  I  .i:iab-(labii-iconi,...,labn>-^conn) 

decs  h  proji^i,.'  exp  :  coni 


n  >  1 

con  =  E(/a6iH4coni, . . . ,  labn^conn) 
decs  h  exp  :  con 

Vi  G  l..n  :  decs  h  expi  :  Sioj.  (iaiii-^coni, . . . ,  labn^ conn)— ^ con' 
decs  h  case™"  exp  of  exp^, . . . ,  exp„  end  :  con' 

decs  h  exp  :  con  Tag  decs  h  exp'  :  con 
decs  h  tag(exp,  exp')  :  Tagged 

decs  h  exp  :  Tagged  decs  h  exp'  :  con  Tag 
decs  h  exp"  :  con— ^ con'  decs  h  exp'"  :  con' 

decs  h  iftagof  exp  is  exp'  then  exp"  else  exp'"  :  con' 

decs  h  mod  ;  [sdecs,  lab:con,  sdecs'] 

BV(sdecs)  n  FV(con)  =  0 
decs  h  mod. lab  :  con 


(62) 

(63) 

(64) 

(65) 

(66) 

(67) 

(68) 

(69) 


Rule  69:  A  projection  is  only  well-formed  if  the  result  is  typable.  If  mod  is  a  value,  the 
projection  is  always  well-formed. 


decs  h  exp  :  con'  decs  h  con  =  con'  :  Cl 
decs  h  exp  ;  con 


(70) 
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3.4.7  Well-formed  Signatures 


decs  h  sdecs  ok 

h  decs  ok 

(71) 

decs  h  •  ok 

decs  h  dec  ok 

decs,  dec  h  sdecs  ok 

lab  ^  dom(s(/ecs) 

(72) 

decs  h  labt>dec,  sdecs  ok 

decs  h  sig  :  Sig 

decs  h  sdecs  ok 
decs  h  [sdecs]  :  Sig 

(73) 

decs,  var-.sig  h  sig' :  Sig 
decs  h  var:sig-^sig'  :  Sig 

(74) 

decs,  var-.sig  h  sig'  :  Sig 
decs  h  var:sig^sig'  :  Sig 

(75) 

3.4.8  Signature  Subtyping 

decs  h  sdecs  <  sdecs' 


-  (76) 

decs  h  •  <  • 


decs,  var'.knd—con  h  sdecs  <  sdecs' 
decs  h  lab>var:knd=con,  sdecs  <  labt>var:knd,  sdecs' 

decs  h  sig  <  sig'  :  Sig 
decs,  var-.sig  h  sdecs  <  sdecs' 

decs  h  lab>var:sig,  sdecs  <  lab>var:sig' ,  sdecs' 

decs  h  lab:  dec  =  lab:  dec' 
decs,  dec  h  sdecs  <  sdecs' 
decs  f-  lab>dec,  sdecs  <  lab>dec',  sdecs' 


(77) 


(78) 


(79) 
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decs  h  sig  <  sig'  :  Sig 


’  decs  h  sdecs  <  sdecs' 

decs  h  [sdecs]  <  [sdecs']  :  Sig 

decs  h  sig2  <  sig^  :  Sig  decs,  var:sig2  l~  sig'i  <  sig'^  :  Sig 
decs  h  var'.siQi-^sig'i  <  var:sig2—^sig'2  :  Sig 

decs  h  sig2  <  sig^  :  Sig  decs,  var:sig2  H  sig'^  <  sig'2  :  Sig 
decs  h  var\sigi—h-sig'i  <  var:sig2—^sig'2  ■  Sig 

decs  h  sig2  <  sig^  :  Sig  decs,  var:sig2  l~  sig'^  <  sig'2  '■  Sig 
decs  h  var:sigi^sig'-^  <  var: sig 2-^ sig'2  ;  Sig 


(80) 

(81) 

(82) 

(83) 


3.4.9  Signature  Equivalence 

decs  h  sdecs  =  sdecs' 


-  (84) 

decs  \-  -  =  ■ 


decs,  var'.knd  h  sdecs  =  sdecs' 
decs  h  lab>var:knd,  sdecs  =  lab>var:knd,  sdecs' 

decs  h  con  =  con'  :  knd  decs,  var:knd=con  h  sdecs  ^  sdecs' 
decs  h  lab>var:knd=con,  sdecs  =  lab>var:knd=con' ,  sdecs' 

decs  h  con  =  con' :  1)  decs,  varicon  h  sdecs  =  sdecs' 
decs  h  labt>var:con,  sdecs  =  lab>var:con',  sdecs' 

decs  h  sig  =  sig'  :  knd  decs,  vav.sig  h  sdecs  =  sdecs' 
decs  h  lab>var:sig,  sdecs  =  lab>var:sig' ,  sdecs' 


(85) 

(86) 

(87) 

(88) 


decs  h  sig  =  sig'  :  Sig 


decs  h  sdecs  =  sdecs' 
decs  h  [sdecs]  =  [sdecs']  :  Sig 

decs  j-  sigi  =  sig2  '■  Sig  decs,  var-sig^  h  sig'^  =  sig'2  :  Sig 
decs  h  var.sigi^sig'i  =  var: sig 2—^ sig'2  :  Sig 

decs  h  sig^  =  sig2  '■  Sig  decs,  var:sig-^  h  sig'^  —  sig'2  :  Sig 
decs  h  vav.sig i-^sig'i  =  var: sig 2—^ sig'2  :  Sig 


(89) 

(90) 

(91) 
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3.4.10 


Well-formed  Modules 


decs  h  sbnds  :  sdecs 
(92) 


decs  h  •  :  • 

decs  h  bnd  :  dec  decs,  dec  h  sbnds  :  sdecs 
decs  \- lab\>bnd ,  sbnds  :  lab> dec,  sdecs 


(93) 


decs  h  mod  :  sig 


t-  decs  ok 

decs  =  decs',  var-.sig,  decs" 

(94) 

decs  h  var  :  sig 

decs  h  sbnds  :  sdecs 
decs  h  [sbnds]  :  [sdecs] 

(95) 

decs,  var:sig  h  mod  :  sig' 

(96) 

decs  h  \var:sig .mod  :  var:sig—^sig' 

decs,  var'.sig  h  mod  4.  sig' 

(97) 

decs  h  \var\sig .mod  :  var: sig sig' 

decs  h  mod  :  sig'—^sig  decs  h  mod'  :  sig' 

(98) 

decs  f-  mod  mod'  :  sig 

Rule  98:  Only  functors  with  non-dependent  types  may  be  applied.  Dependencies  can  be  elimi¬ 
nated  by  uses  of  the  subtyping  and  equivalence  rules.  If  the  argument  is  a  value,  dependencies 
can  always  be  eliminated. 


decs  h  mod  :  [sdecs,  lab'.sig,  sdecs'] 
BV(s(iecs)  n  FV(5t^)  =  0 
decs  h  mod. lab  :  sig 


(99) 


Rule  99:  A  projection  is  only  well-formed  if  the  result  can  be  given  a  signature  in  the  ambient 
context.  If  mod  is  a  value,  this  can  always  occur. 


decs  h  mod  :  sig 
decs  h  mod'.sig  :  sig 


(100) 


Rule  100:  Ascription  of  a  signature  to  a  module  can  make  types  in  mod  abstract  by  forgetting 
equations. 


decs  h  modv  :  [sdecs,  lab>var:knd,  sdecs' _ 

decs  h  mody  :  [sdecs,  lab>var\knd—mody.lab,  sdecs' 


(101) 
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Rule  101:  The  “self”  rule.  If  mod. labs  specifies  a  type  and  mod  has  a  well-defined  value  then 
mod.labs  =  mod.labs;  we  add  this  fact  to  the  signature. 


decs  h  modv  :  [sdecs,  lab>var\sig ,  sdecs'] 
decs  h  mody.lab  :  sig' 

decs  h  modj ;  [sdecs,  lab>var\sig' ,  sdecs'] 
Rule  102:  The  “self”  rule  can  be  recursively  applied. 

decs  h  mod  :  sig  decs  h  sig  <  sig'  :  Sig 
decs  h  mod  :  sig' 


(102) 


(103) 


3.4.11  Valuability 


decs  h  exp  :  con  decs  h  exp 
decs  h  exp  4^  con 


decs  h  exp  4-  con 


(104) 


decs  h  mod  :  sig  decs  h  mod  4. 
decs  h  mod  4  sig 


decs  h  mod  4-  sig 


(105) 


decs  h  exp  4- 


decs  h  expy  4 

(106) 

decs  h  mod  4- 
decs  h  mod. lab  4 

(107) 

decs  h  expi  4-  con' ^ con  decs  h  exp2  4 

decs  h  expi  exp2  4 

(108) 

decs  f-  expi  4-  •  •  •  decs  h  4- 

decs  h  {labi=exp^,  •  •  • ,  labn=exp^}  4 

(109) 

decs  h  exp  4 
decs  h  TCiab  exp  4 

(110) 

decs  h  exp  4 
decs  h  roll'^®"  exp  4 

(111) 

decs  h  exp  4 
decs  h  unroll  exp  4 

(112) 
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decs  h  exp  4- 
decs  h  inj^„7  exp  i 


(113) 


decs  h  proj;“"  exp  I 

decs  h  exp  4  decs  h  exp' 
decs  h  tag{exp,  exp')  I 

decs  h  exp  4^ 

decs  h  exp  I  i  ■  decs  h  ea:p„  4' 
decs  h  case™"  exp  of  expi, . . . ,  exp^  end  | 


(114) 

(115) 


(116) 


decs  h  •  4- 

decs  h  exp  I  con  decs,  vav.con  h  shnds 
decs  h  lab>var=exp,  sbnds  4- 


decs  h  sbnds  4^ 

(117) 

(118) 


decs  h  con  :  knd  decs,  var\knd=con  h  sbnds  I 
decs  h  lab>var=con,  sbnds  4- 


decs  h  mod  sig  decs,  var:sig  h  sbnds  \. 
decs  h  lab>var=mod,  sbnds  i 


(119) 

(120) 


decs  h  mody  4^ 

decs  h  sbnds  4- 
decs  h  [sbnds]  4, 

decs  h  mod  4^  sig'-^sig  decs  h  mod'  4. 
decs  h  mod  mod'  i 

decs  h  mod  4- 
decs  h  mod.lab 

decs  h  mod  4. 
decs  h  mod: sig  4- 


decs  f-  mod  4^ 

(121) 

(122) 

(123) 

(124) 

(125) 
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4  Dynamic  Semantics 

4.1  Introduction 

The  dynamic  semantics  of  the  internal  language  is  a  call-by-value  operational  semantics 
presented  as  a  rewriting  system  on  states  of  an  abstract  machine.  The  presentation  is 
strongly  influenced  by  the  work  of  Plotkin  [PI08I]  and  Wright  and  Felleisen  [WFflljPand  is 
a  significant  departure  from  the  framework  employed  in  The  Definition.  In  particular  we 
employ  a  small  step  semantics  in  which  transitions  represent  basic  evaluation  steps  of  an 
abstract  machine.  We  rely  on  substitutionFrather  than  environments;  values  are  particular 
expressions  of  the  language.  Exception  propagation  is  handled  by  explicitly  maintaining 
the  evaluation  contextFrather  than  relying  on  implicit  rules  for  exception  propagation.  We 
maintain  a  store  for  assignable  cellsPas  in  The  DefinitionTsind  a  typing  context  which  types 
locations  and  dynamically-created  tags  associated  with  values  of  type  Tagged;  these  are  the 
only  extra-linguistic  constructs  in  the  formalism.  As  Wright  and  Felleisen  have  demonstrated 
these  could  be  made  part  of  the  language  by  introducing  a  letref  construct. 

Each  state  E  of  the  abstract  machine  is  a  four-tuple  of  the  form 

(A,  a,  E,  phrase), 


where 


•  A  is  a  typing  context  {decs)  for  locations  and  tags  created  at  run-time.  This  maintains 
a  record  of  what  exception  tags  and  locations  have  been  allocatedFand  is  also  used  in 
our  soundness  proofs. 

•  (7  is  a  finite  mapping  from  locations  (/oc’s)  typed  in  A  to  expression  values  {expf).  The 
syntax  for  all  internal  language  values  appeared  in  Figure  4. 

•  E  is  a  stack  of  evaluation  frames  (see  Figure  5).  This  represents  an  implementa¬ 
tion’s  control  stackFor  equivalentlyFthe  current  continuation.  Appending  two  stacks 
corresponds  to  composition  of  continuations;  accordinglyPwe  write  EoE'  for  the  con¬ 
catenation  of  E  and  E'Pdefined  in  the  obvious  way.  The  meta-variable  R  ranges  over 
control  stacks  that  do  not  contain  a  frame  of  the  form  “handle  []  with  exp”. 

•  phrase  is  an  expressionFmodulePor  constructor. 

We  let  T,t  range  over  the  set  of  terminal  statesPwhere  a  state  is  called  terminal  if  it  has 
one  of  the  forms: 

(A,  a,  [],  val)  normal  termination 

(A,  a,  [],  raise exp„)  uncaught  exception 

All  other  states  are  called  nonterminal. 

The  dynamic  semantics  is  a  transition  relation  E  S'  between  states.  As  usualPwe 
denote  the  reflexiveFtransitive  closure  of  by  <-4*. 
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F  ::=  []  exp 

I  expy  [] 

I  {rbndsy,  lab=W,  rbnds} 

I  TT/ofr  0 

I  handle  []  with  ea:p 
I  raise"""  [] 

I  ref"""0 
I  getD 

I  set([],e2:p) 

I  set  {expy,  []) 

I  roll"""[] 

I  unroll  0 

I  50 
I  injro 
I  projTO 

I  case"""  []  of  expi , ,  exp.^  end 
I  tag(ea;pv,  []) 

I  iftagof  []  is  exp'  then  exp"  else  exp'" 

I  iftagof  expy  is  []  then  exp"  else  exp'" 
I  W.lab 

I  [sbndsy,  lab>var=^,  sbnds] 

I  []  mod 
I  mody  [] 

I 


E  ::= 


[] 

E  o  F 


Figure  5:  Evaluation  Frames 


4.2  Transition  Relation 

4.2.1  Search  for  Next  Redex 

(A,  cr,  E,  exp  exp')  (A,  a,Eo  ([]  exp'),  exp)  (126) 

(A,  cr,  o  ([]  exp),  expy)  (A,  a,E  o  [expy  []),  exp)  (127) 

(A,  a,  E,  {rbndsy,  lab=exp,  rbnds}) 

(A,  o,E  o  {rbndsy,  lab—^,  rbnds},  exp)  (128) 

if  exp  is  not  a  value 

(A,  a,E  o  {rbndSy,  lab=[],  rbndSy'},  expy)  >  (A,  a,  E,.{rbndSy,  lab—expy,  rbndSy'})  (129) 
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(A,  a,Eo  {rhnds^,  /a6=[],  rbnds^',  lab'=exp',  rbnds},  expy)  M- 
(A,  a,Eo  (rbndsy,  lab=expy,  rbndsy',  lab'=[],  rbnds},  exp') 

if  exp'  is  not  a  value 

(A,  (J,  E,  TTiab  exp)  M-  (A,  a,Eo  []) ,  exp) 
if  exp'  is  not  a  fix  value 

(A,  a,  E,  handle  exp  with  exp')  M-  (A,  a,Eo  (handle  []  with  exp'),  exp) 

(A,  a,  E,  raise exp)  (A,  a,E  o  (raise®"”  []),  exp) 

if  exp  is  not  a  value 

(A,  a,Eo  (raise®"”  []),  expy)  (A,  a,  E,  raise®"”  expy) 

(A,  a,  E,  ref®""  exp)  ■->  (A,  a,Eo  (ref®""  []),  exp) 

(A,  a,  E,  get  exp)  (A,  a,Eo  (get  []),  exp) 

(A,  a,  E,  set  {exp,  exp'))  (A,  a,Eo  (set  ([],  exp')),  exp) 

(A,  a,Eo  (set  ([],  exp)),  expy)  (A,  a,Eo  (set  {expy,  [])),  exp) 

(A,  a,  E,  roll®""  exp)  -4  (A,  a,Eo  (roll®""  []),  exp) 

if  exp  is  not  a  value 

(A,  a,Eo  (roll®"”  []),  expy)  (A,  a,  E,  roll®"”  expy) 

(A,  a,  E,  unroll  exp)  (A,  o,E  o  (unroll  []),  exp) 

(A,  a,  E,  d  exp)  -4  (A,  o,Eo{d  []),  exp) 
if  exp  is  not  a  value 

(A,  o,Eo{d  []),  expy)  (A,  a,  E,  d  expy) 

(A,  a,  E,  injl^j"  exp)  -4  (A,  a,Eo  (injj®"^"  []),  exp) 

if  exp  is  not  a  valne 

(A, <7,  B  o  (injgj”  0),  eip,)  ^  (A,  <r,  E,  injjji"  exp^) 

(A,  <T,  E,  pmjS  exp)  ^  (A,  cr,  B  o  (proj?;j'  []),  exp) 


(130) 

(131) 

(132) 

(133) 

(134) 

(135) 

(136) 

(137) 

(138) 

(139) 

(140) 

(141) 

(142) 

(143) 

(144) 

(145) 

(146) 
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(A,  (T,  E,  tag{exp,  exp'))  ^  (A,  a,Eo  (tag([],  exp')),  exp) 

if  exp  or  exp'  is  not  a  value 

(A,  cr,Eo  tag([],  exp),  exp^)  M-  (A,  a,Eo  {tag{expy,  [])),  exp)  (148) 

(A,  a,Eo  {tag{expy,  [])),  expy)  ^  (A,  a,  E,  tag{expy,  expy'))  (149) 

(A,  a,  E,  iftagof  exp  is  exp'  then  exp"  else  exp'")  ^  (150) 

(A,  a,Eo  (iftagof  []  is  ea^p'then  exp"  else  exp'"),  exp) 

(A,  a,E  o  (iftagof  []  is  exp'  then  exp"  else  exp'"),  expy)  ^ 

(A,  a,Eo  (iftagof  expy  is  []  then  exp"  else  exp'"),  exp') 

(A,  a,  E,  [lah\>var=phrase,  sbnds])  M-  (152) 

(A,  a,Eo  [lab>var=[],  sbnds],  phrase) 

(A,  a,E  o  [sbndsy,  lab>var=[\, 

lab'>var' =phrase,  sbnds],  val)  (153) 

(A,  <t,E  o  [sbndSy,  lab>var=val, 

lab'>var'=[],  {val /var} sbnds],  [val/ var} phrase) 

(A,  a,Eo  [sbndSy,  lab>var=[]],  val)  (A,  a,  E,  [sbndSy,  lab>var=val])  (154) 
{A,  a,  E,  mod. lab)  ^  {A,a,E  o[].lab,mod)  (155) 

(A,  a,  E,  mod  mod')  ^  (A,  a,Eo  ([]  mod'),  mod)  (156) 

(A,  a,E  o  ([]  mod'),  mody)  (A,  a,Eo  {mody  0),  mod)  (157) 

(A,  a,  E,  mod-.sig)  M-  (A,  (7,Eo  mod)  (158) 

4.2.2  Reduction 

{A,a,Eo{ expy^  [] ) ,  expy)  ^ 

(A,  a,  E,  {expy^/var'i}  •  •  •  {expy^/var'J{expy/varj}expj) 
where  VA;  G  l..n  : 

expv''  =  {d)Trj^i\y(.{var'i{vari:coni):con'j}-^expi)^^iend 
(A,  g,E  o  (TTjoft  []),  {rbndSy,  lab—expy,  rbndsy  })  '  ^  (^)  oxpy)  (160) 

(A,  a,E  o  (handle  []  with  exp),  expy)  ^  (A,  a,  E,  expy)  (161) 
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(162) 


(A,  a,E  o  (ref‘^°"  []),  expy)  {A[loc:con],  a[loct-^expv],  E,  loc) 

if  loc  ^  BV(A) 

(A,  a,Eo  (get  []),  loc)  (A,  a,  E,  expy) 

if  a{loc)  =  expv 

(A,  a,Eo  (set  {loc,  [])),  exp„)  (A,  a[loc>-^expy],  E,  {}) 

(A,  a,E  o  (unroll  []),  roir""'  expy)  M-  (A,  a,  E,  expy) 

(AjCr, new_tag[con])  {A[tag:conTBg],(7,E,tag) 

if  tag  ^  BV(A) 

(A,  o,Eo  {pro'fi°^'  0),  expy)  (A,  a,  E,  expy) 


(163) 

(164) 

(165) 

(166) 
(167) 


(A,  a,Eo  (case“"  []  of  exp^, exp^  end), 
(A,cr,  E,  expf.  exp^) 


labn^conn)  ^ 


(A,  a,Eo  (\hagoft.ag{tag,  expy)  is  []  then  exp"  else  exp'"),  tag)  M- 
(A,  a,  E,  exp"  expy) 


(A,  a,Eo  (iftagof  tag(fafif, 
(A,  (j,  E,  exp'") 


expy)  is  []  then  exp"  else  exp'"),  tag')  ^ 

if  tag  ^  tag' 


(A,  (t,E  o  {{Xvar-.sig.mod)  []),  mody) 
(A,  (7,  E,  {mody/var}mod) 


(A,  a,E  o  []:si5',  mody)  M-  (A,  a,  E,  mody) 


(168) 

(169) 

(170) 

(171) 

(172) 


(A,  <t,E  o  (handle  []  with  exp')  o  R,  raise‘s®"  expy)  M- 
(A,  a,  E,  exp'  expy) 

(A,  a,  R,  raise“"  expy)  m-  (A,  a,  0,  raise“"®  expy) 


(173) 

(174) 
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5  External  Language 

5.1  Notation 

As  in  the  Pe^init^onroptional  elements  are  enclosed  by  single  brackets  (•  •  •)  or  double  brackets 
((•  •  •)).  For  the  purposes  of  this  grammarFall  optional  choices  are  completely  independent. 


5.2  Grammar  of  the  Abstract  Syntax 

The  (disjoint)  base  syntax  classes  include  scon  (syntactic  constants)riyuar  (type  variables)r 
id  (core-level  identifiers) F^ycon  (type  constructors) Fsirid  (structure  identifiers) Fand 
(functor  identifiers).  As  in  The  Definition  of  Standard  MlFall  but  the  first  two  have  corre¬ 
sponding  “long”  formsFcontaining  a  finite  sequence  of  structure  identifiers  as  as  prefix. 


expr  scon 
I  longid 

1  ilabi  =  expr^ ,  ■  ■  ■  ,  labn  =  expr^f} 
I  let  strdec  in  expr  end 
I  expr  expr' 

I  expr  :  ty 
I  expr  handle  match 
I  raise  expr 
I  f  n  match 
I  expri  =  expr^ 


mrule  pat  =>  expr 
match  ::=  mrule 

I  mrule  I  match 


strdec  ::=  • 

I  val  ityvar^ ,  •  •  •  .tyvar^^)  pat  =  exp 
I  val  (.tyvar^ ,  ■■■  .tyvar^f)  rec  pat  =  exp 
I  strdeci  strdec2 
I  open  longidi  •  •  •  longid^ 

I  exception  id 
I  exception  id  of  ty 
I  exception  id  =  longid 
I  local  strdeci  in  strdec2  end 
I  type  tybind 
I  datatype  datbind 

I  datatype  {tyvari,  •  •  •  ,tyvar^)  tycon  = 

datatype  (tyvari ,  ■  •  •  ,  tyvar^)  longtycon 
I  structure  strbind 
I  functor  funbind 
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tybind 

datbind 

conbind 

strexp 

spec  :: 


typdesc  :: 

etypdesc 
sigexp  :: 

pat  :: 


(.tyvar^,  ■  ■  ■  ,tyvar^)  tycon  =  ty  (and  tybind) 

(.tyvavi ,  ■  •  •  ,  tyvaVj^)  tycon  =  conbind 

(and  datbind) 

id  (of  ty)  ((I  conbind)) 

longstrid 

struct  strdec  end 
longfunid  (.longstrid) 
longstrid  :  sigexp 
longstrid  :>  sigexp 
let  strdec  in  strexp  end 

val  id  :  ty 
type  typdesc 
eqtype  etypdesc 
datatype  datbind 

datatype  (tyvari,  ■  ■  ■  ,tyvar.^)  tycon'  = 
datatype  (tyvar^ ,  •  •  •  ,tyvar^)  longtycon 
exception  id 
exception  id  of  ty 
structure  strid  :  sigexp 
functor  funid  (strid  :  sigexp)  :  sigexp' 
include  sigexp 
speCi  spec2 

spec  sharing  type  longidi  =  longid2 

--  (tyvari  ,•  •  • ,  tyvar.^)  tycon  (and  typdesc) 

I  (tyvari  >  '  >  tycon  =  iy  (and  typdesc) 

-  (tyvari ,  •••  ,  tyvar,^)  tycon  (and  etypdesc) 

-  sig  spec  end 

I  sigexp  where  type  (tyvari ,  •  •  •  ,tyvar^)  longtycon  =  ty 

-  scon 

1  longid 

I  pat  :  ty 
I  longid  pat 

[  lab  I  ~  pat  I  j  '  *  *  1  labfi  “  patj^^  ( j .  •  • 

I  pati  as  pat2 
I  ref  pat 
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iy 


strbind  ::= 
funbind  ::= 


base 

tyvar 

ilabi  :  tyi,  ■■■  , labn  :  tyj- 
ityi,  ■■■  ,tyj  longtycon 
ty  ->  ty' 

strid  =  strexp  (and  strbind) 

funid  (strid  :  sigexp)  =  strexp  (and  funbind) 


5.3  Syntactic  Restrictions 

•  No  record  expressionFrecord  patternFor  record  type  may  contain  duplicate  field  labels. 
No  tyvar  may  appear  more  than  once  in  a  single  sequence. 

•  Any  type  variable  occuring  in  a  conbind  must  also  appear  in  the  enclosing  datbind. 
Any  type  variable  appearing  in  the  ty  of  a  where  type  must  appear  in  the  type  variable 
sequence. 

•  No  valFtypeFdatatypeFexceptionFstructureF  signature  or  functor  strdec  or 
spee  may  bind  the  same  identifier  twice;  this  applies  also  to  value  constructors  within 
a  datbind. 

•  In  a  val  rec  declarationFthe  pattern  must  be  of  the  form 

'(lab'^  idi^  I  *  *  *  >  labfi“idYiy 
and  the  expression  must  be  of  the  form 

-CZa6i=f  n  matchi ,  •  •  •  ,  labn=fn  matchny. 

The  “ .  .  .  ”  EL-notation  may  not  appear  in  the  pattern. 
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6  Elaboration 

6.1  Introduction 

In  addition  to  type-checking  and  type-reconstructionFthe  elaborator  performs  the  following 
tasks: 

1.  Datatypes  are  expanded  into  structures  and  signatures  whose  components  include 

•  an  abstract  type  (implemented  as  a  recursive  sum  type); 

•  operations  corresponding  to  datatype  constructors  as  values  (those  datatype  con¬ 
structors  which  carry  values  are  total  functionsF  while  non  value-carrying  con¬ 
structors  are  constants  of  the  abstract  type); 

•  an  “expose”  operation  which  presents  datatype  values  as  elements  of  a  (tagged) 
sum  type. 

The  “generativity”  of  datatypes  is  handled  via  signature  ascription;  the  type  is  made 
opaque  and  is  therefore  inequivalent  to  any  previous  type.  The  matching  of  datatypes 
in  signatures  reduces  to  the  matching  of  substructures. 

2.  Polymorphism  (including  equality  polymorphism)  is  encoded  as  a  use  of  the  modules 
system.  Polymorphic  values  are  translated  into  functorsP which  can  be  explicitly  in¬ 
stantiated  with  structures  of  types  (and  equality  functions).  More  preciselyPthe  functor 
takes  a  structure  containing  type  constructors  of  kind  9,  (for  types  which  the  polymor¬ 
phic  value  requires  to  be  equality  typesPthe  structure  also  contains  equality  functions 
for  the  instantiating  types);  the  functor  returns  a  structure  whose  single  component 
(with  label  “it”)  is  the  polymorphic  value  made  monomorphic  by  instantiating  it  with 
the  given  types. 

3.  Equality  polymorphismPas  just  mentionedPand  equality  types  are  handled  by  explicitly 
constructing  and  passing  equality  functions  as  needed.  We  do  not  explicitly  distinguish 
types  that  admit  equality;  ratherPa  type  admits  equality  iff  the  equality  compiler  can 
create  an  equality  function  for  this  type. 

4.  We  make  explicit  the  propagation  of  abstract  types  defined  locally  to  module-level  let 
and  local  constructorsPor  hidden  through  the  use  of  transparent  signature  ascription. 
In  particularPthe  “hiding”  effect  of  these  constructs  on  types  is  implemented  as  renam¬ 
ing  rather  than  simple  scoping.  This  is  necessary  to  obtain  the  same  type  propagation 
behavior  as  the  stamp-based  semantics  of  The  Definition. 

5.  Patterns  are  expanded  into  uses  of  the  appropriate  record  projections  and  datatype 
deconstructors.  Thus  the  elaboration  specifies  a  reference  pattern  compiler. 

6.  Each  series  of  external  language  bindings  {strdec)  elaborates  into  a  structurePcontain- 
ing  a  component  for  every  variable  bound  in  the  external  language.  External  language 
identifiers  correspond  to  internal  language  labels. 
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7.  Some  structure  labels  are  explicitly  marked  with  an  asterisk  (lab*).  This  indicates  that 
the  structure  is  “open”  for  the  purposes  of  identifier  lookup.  (See  the  lookup  rules  for 
more  details.) 

8.  All  coercive  aspects  of  the  signature  matching  relation  (the  reordering  and  forgetting 
of  components)  are  handled  by  introducing  explicit  coercion  functors  witnessing  the 
relation.  This  makes  the  order  and  number  of  components  of  a  structure  apparent 
from  its  signatureFthough  there  is  a  run-time  cost  to  signature  ascription. 

6.2  Notation 

•  The  overbar  function  ~  maps  each  EL  identifier  to  an  IL  label.  We  assume  that 
this  function  is  injectiveFthat  the  range  is  coinfinite  in  the  set  of  IL  labelsFand  that 
identifiers  of  different  classes  map  to  different  labels.  In  particularFwe  assume  that 
the  parser  distinguishes  between  the  classes  of  expression  variablesFtype  constructorsF 
type  variablesFstructure  identifiersFsignature  identifiersFand  functor  identifiers.  How- 
everFwe  do  not  distinguish  between  an  identifier  being  used  as  an  expression  variableF 
datatype  constructorFor  exception  constructor. 

The  distinguished  labels  “eq”F“expose”F“it”Fand  “tag”  used  by  the  elab orator  are  not 
in  the  range  of  the  overbar  mappingFand  other  labels  chosen  to  be  fresh  are  similarly 
not  in  the  range  of  the  mapping. 

We  extend  the  overbar  mapping  component-wise  to  long  identifiersF which  thus  map 
to  sequences  of  labels. 

•  Optional  elements  are  enclosed  in  single  or  double  angle  brackets.  For  each  ruleFeither 
all  or  none  of  the  elements  in  single  angle  brackets  must  be  presentFand  similarly  all 
or  none  of  the  elements  in  double  angle  brackets  must  be  present.  Single  and  double 
angle  brackets  in  the  same  rule  represent  two  independent  choices. 

•  In  some  casesFthe  optional  element  notation  is  insufficient.  ThereforeFwe  have  the 
additional  notation 

elementi 
or 

element^ 

which  means  that  either  elementi  or  element^  must  be  present.  If  there  are  multiple 
such  choices  in  a  single  ruleFthis  means  that  either  the  first  element  should  always  be 
chosen  in  all  casesFor  the  second  element  must  be  chosen  in  all  cases. 

An  extension  of  this  notation  gives  the  choices  subscripts.  Then  all  choices  with  the 
same  subscript  must  agree  (all  first  element  or  all  second  element)  but  two  choices  with 
different  subscripts  are  completely  independent. 

•  The  elaboration  maintains  an  elaboration  context  FFwhich  is  simply  a  list  of  structure 
declarations  (sdecs)  except  that  we  allow  duplicate  labels.  When  F  appears  in  an  IL 
judgment  where  decs  is  expectedFthere  is  an  implicit  coercion  which  drops  all  top-level 
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labels  and  all  signature  declarations.  We  extend  the  notion  of  variable  bindings  from 
Section  2.5  with  the  following: 


Function 

Definition 

BV(F) 

BV(sdec,  F)  =  {BV(sdec)}  U  BV(F) 

dom(F) 

dom(sdec,  F)  =  {dom(sdec)}  U  dom(F) 

Binding  Phrase 

Bound  Vars 

Scope 

sdec,  F 

BV(sdec) 

F 

•  We  use  an  operation  of  “syntactic  concatenation  with  renaming”  for  sbnds  andFin 
parallelFfor  sdecs.  This  is  defined  by: 

{■++sbnds')  :  {■++sdecs')  :=  sbnds'  :  sdecs' 

{lab^*'^>bnd,  sbnds++sbnds')  :  {lab^*'>>bnd,  sdecs-\-\- sdecs')  := 

r  lab^*^>bnd,  sbnds"  :  lab^*^>dec,  sdecs"  if  lab^*^  ^  dom{sbnds") 

\  lab'^*^t>bnd,  sbnds"  :  lab'^*^t>dec,  sdecs"  otherwiseFwhere  lab'^*'^  ^  dom{sbnds") 
where  sbnds++sbnds' :  sdecs++sdecs'  =  sbnds"  :  sdecs" 

6.3  Initial  Basis 

The  elaborator  assumes  the  presence  of  a  structure  basis  :sigj,g^gig  serving  as  the  initial  basis 
for  the  internal  language.  It  must  contain  at  least  the  following  fields  which  define  three 
exceptions: 

Bind*  :[tag:UnitTag, Bind:Tagged], 

Mat  ch* :  [tag:  U  nit  Tag,  Mat  ch:Tagged] , 
fair  :[tag:UnitTag,  faihTagged]]. 


6.4  Derived  Forms 

The  translation  also  makes  use  of  a  number  of  derived  forms  of  kindsF  constructorsF  and 
expressions.  These  are  shown  in  Figure  6. 

The  representation  of  tuples  as  records  with  numbered  fields  is  copied  from  SML.  The 
encoding  of  multi-argument  functions  as  single-argument  functions  is  also  very  standardFas 
is  the  encoding  of  booleans  as  a  sum  type. 

The  purpose  of  the  catch  form  is  to  serve  as  a  special  handler  for  the  “fail”  exceptionF 
and  to  propagate  all  other  exceptions.  The  fail  exception  is  only  used  by  the  elaborator  to 
signal  a  failure  in  pattern-matching. 
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kndiX  ■  ■  ■  xkndn 
kndT 

Unit 

B00l(;ab) 

con-i  X  •  •  •  X  con-n 
\{vari, varn)-con 
{coni,  COUn) 

{expi,  •  •  • ,  expn) 
X{var:con):con' .  exp 

X{vari:coni, . . . ,  varn-conn)- 


let  bndi, . . . ,  bndn  in  exp  end 
fail"" 

catch"”  exp  with  exp' 


pproj^r' . 


false 

true 

if  expi  then  exp2  else  exp^ 
expi  and  exp2 

,  var^^'').exp 


V(uarf‘^^\  . . . ,  varn^^'").con 


h-)-  {l:A:ndi, . . . ,  n:kndn} 
1-4  {l:knd, . . . ,  n:knd} 


1-4  S(/o6)  (TH4Unit,2i-4Unit) 

1-4  {l=coni,  •  •  •  ,n=con„} 

1-4  Xvar-.QJ' .{{tti  var/vari}  ■  ■  •  {7r„  var/varn}con) 

1-4  {l=coni, . . . ,  n=con„} 

1-4  {l^expi,  ■  ■  •  ,n=ea:p„} 
h4  TTjfix  var'{var\con)'.con'^expen6 
var'  ^  FV(ercp) 

.exp  1-4  X{var\coni x  •  •  •  x conn)\con. 

{tti  var/ vari]  •  •  •  {7r„  var/ var n} exp 
var  ^  FV{exp) 

1-4  [l=bndi, n=bndn,  {n  +  l)=ea;p].(n  +  1) 

h4  raise""  6asi5.fair.fail 

1-4  handle  exp  with  (AwarTagged. 

iftagof  var  is  ftasis.fail*. tag  then  At;ar;Unit.e2;p'  else  raise""  va'i 
var  ^  FV(ea;p') 

1-4  case""'  exp  of 

Avarxon'^^jj. raise""'  exp', 

Xvar\con'i^f,..pxo]i^f,.  'var,... 

Avar: raise""'  ea;p'end 

where  —  "^(lab)  {labif-^coni, . . . ,  labn'-^conn) 

H4  injf  {} 

^  injf-'  {} 

h4  case^°°'  exp]^  of  A?;ar’:BoolY.ea;p3,  Xvar:'Qoo\2.exp2  end 
var  ^  FV(ea;p2,  expZ) 

1-4  if  expi  then  exp2  else  false 

1-4  A(var:[l*:[l>wari:fi(,  eq:aariXaari-^Bool)i], . . . , 
n* : [n>varn'-Fl{,  eq: uar„  x  mr„-^Bool)„]]) . 
[it={uar.l*.l/?;ari}  •  •  •  {var.n*.n/varn}exp] 

1-4  (aar:[l*:[l>t;ari:f^(,  eq:?;ariXt;ari-^Bool)i], . . . , 
n*:[n>uar„:fi(,  eq:?;ar„x  var„— ^Bool)„]])  — >■ 
[it:{t;ar.l*.l/aari}  ■  •  ■  {var.n*.n/varn}con] 


Figure  6:  Derived  Forms 
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6.5 


Judgment  Forms 


Judgment... 
r  h  expr  exp  :  con 
r  h  match  ^  exp  :  con 
r  h  strdec  ^  sbnds  :  sdecs 
r  h  strexp  mod  :  sig 
r  h  spec  ^  sdecs 

r  h  sigexp  sig  :  Sig 

r  b  ty  con  : 

r  h  tybind  sbnds  :  sdecs 

r  h  datbind  sbnds  :  sdecs 

r  f^tx  lO'bs  path  :  class 
r  hjtx  lo-bs  ^  path 

decs]  path: sig  i^ig  labs  labs'  :  class 

sig  iiig  lab  labs' 

■  decs  [sbndsy]  :  [sdecs'] 

r  h  pat  exp  :  con  else  exp  sbnc 


Meaning. . . 
expression 
pattern  match 
declaration 
structure  expression 
signature  specification 
signature  expression 
type  expression 
type  definition 
datatype  definition 

lookup  in  r 
lookup  in  signature 

polymorphic  instantiation 
:  sbnds  pattern  compilation 


decs  fiq  con  ^  exp^ 

decs  liub  path  :  sigQ  sig  mod  :  sig' 
decs]  path: sig Q  l^ub  sdec  sbnd  :  sdec' 

sig  hrt  labs  :=  con  :  knd  sig'  :  Sig 
sig  lih  labs  :=  labs'  :  knd  sig'  :  Sig 


equality  compilation 
coercion  compilation 


impose  definition 
impose  sharing 


6.6  Translation  Rules 


6.6.1  Expressions 


r  h  scon  scon  :  type(scon) 


r  h  expr  exp  :  con 

(175) 


Rule  175:  We  assume  a  meta-level  function  type  which  gives  the  IL  type  of  each  constant. 


r  f^tx  longid  path  :  con 
Rule  177  does  not  apply. 

r  h  longid  ^  path  :  con 
Rule  176:  Monomorphic  variables. 


(176) 
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r  f^tx  longid  path  :  con^con' 
r  h  longid  d  (path)  :  con^con' 


(177) 


Rule  176:  Monomorphic  datatype  or  exception  constructors.  Because  the  IL  has  no  sub¬ 
sumption,  these  must  be  coerced  to  a  partial  function  type  when  used  as  function  values  (not 
immediately  applied). 


r  f5tx  longid  ^  path  :  [it:  con] 

r  rnod  :  sig 

Rule  179  does  not  apply, 
r  h  longid  path{mod). it :  con 

Rule  178:  Instantiation  of  polymorphic  variables.  All  polymorphic  functions  are  translated 
into  total  functors  whose  body  contains  a  single  component  with  the  label  “it” .  The  module 
mod  is  the  structure  of  types  (and  equality  functions,  if  needed)  that  are  used  to  instantiate 
the  polymorphic  function. 


r  ijtx  longid  ^  path  :  > [it:  con— > con'] 

_ r  linst^  rnod  :  sig _ _ 

r  h  longid  ^  d  {path{niod). it)  :  con^con' 


(179) 


Rule  179:  Instantitaion  of  polymorphic  datatype  constructors.  As  in  Rule  176,  we  coerce  to  a 
partial  function  type. 


a  a  permutation  of  l..n 
vari,  •  •  • ,  yarn  ^  BV (F) 

labg^fi'j  lab^^fi'j 

r  h  expV]^  ^  expi  :  coni  •  •  •  F  h  expr^  oxp^  :  con„ 

F  h  -ilabi  =  expri,---,labn  =  expr^} 

let  vari=expi, . . . ,  varn=exp^  in  {(a(>(r(i)=wa?'o.(i),  •  •  •  ,vdf^^=var end  : 

:  C0n(7(i) ,  '  ■  '  >  ^®^(T{n)-C^^<T(n)} 

Rule  180:  The  order  in  which  labels  appear  in  the  record  type  is  significant  for  the  IL  but  not 
the  EL,  so  in  the  translation  we  normalize  record  values  and  types  by  sorting  the  labels  with 
some  fixed  ordering  <.  The  order  in  which  effects  occur,  however,  is  determined  by  the  order 
of  the  expressions  in  the  EL. 


F  h  strdec  sbnds  :  sdecs 

var  ^  BV(F)  F,  l*>var:[sdecs]  h  expr  ^  exp  :  con' 

F,  var:[sdecs]  h  con'  =  con  :  Q,  F  h  con  : 

F  h  let  strdec  in  expr  end  let  var=[mod]  in  exp  end  :  con 


(181) 
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Rule  181:  The  “starred  label”  convention  is  used  here  to  make  the  locally-defined  bindings 
accessible  while  translating  expr.  The  elaborator  verifies  that  the  translated  expression  can 
be  given  a  a  type,  which  must  not  depend  on  any  abstract  types  (e.g.,  datatypes)  defined  in 
strdec. 


r  h  expr  ^  exp  :  con” ^  con 
r  h  expr'  ^  exp'  :  con' 
r  h  con'  =  con''  :  VL 

r  h  expr  expr'  ^  exp  exp'  :  con 

Rule  182:  General  application. 


(182) 


r  f^tx  longid  path  :  con' ^  con 
r  h  expr'  exp'  :  eon' 

T  h  longid  expr'  exp  exp'  :  con 


(183) 


Rule  183:  Application  of  a  monomorphic  datatype  constructor,  which  is  valuable  if  expr'  is 
valuable. 


r  h^tx  longid  path  :  sig—^[it\con'^con] 
r  mod  .  sig 

r  h  expr'  exp'  :  con' 

r  h  longid  expr'  {path  (mod). it)  exp'  :  con 


(184) 


Rule  184:  Application  of  a  polymorphic  datatype  constructor,  which  is  valuable  if  expr'  is 
valuable. 


r  h  expr  ^  exp  :  con 
T  \-  ty  con'  :  Q,  F  h  con  =  con'  :  Q. 

r  h  expr  :  ty  exp  :  con 


(186) 


Rule  185:  Type  constraints  on  expressions  are  verified,  but  do  not  appear  in  the  translation. 


r  h  expr  exp  :  con 
r  h  match  exp' :  Tagged— ^con' 
r  h  con  =  con' :  Q, 

_ var  i  BV(r) _ 

r  h  expr  handle  match  ^ 
handle  expmth 

A(t;ar:Tagged):con.(catch“"  exp'  warwith  raise*^®"  var)  : 
con 

Rule  186:  The  handling  expression  exp'  var  will  fail  if  the  handler  pattern  does  not  match  the 
exception  caught  by  the  IL  handle,  in  which  case  we  re-raise  the  exception. 
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r  h  expr  exp  :  Tagged  F  h  con  :  Q 
r  h  raise  expr  ^  raise'^®”  exp  :  con 


(187) 


Rule  187:  raise  expressions  can  be  given  any  (valid)  type.  To  preserve  the  property  that  every 
IL  expression  has  a  unique  type  up  to  equivalence,  we  annotate  the  IL  raise  with  this  type. 


r  h  match  exp  :  coni—^con2  var  ^  BV(r) 
r  h  f  n  match  ^ 

A(uar:coni);con2.(catch‘^°"^  exp  uar  with  raise'^®”^  feasis. Match*. Match)  : 
coni—^con2 


(188) 


Rule  188:  The  application  exp  var  will  fail  if  the  match  fails;  we  turn  the  failure  into  a  match 
exception.  The  resulting  function  has  a  partial  type  because  it  can  (syntactically)  raise  an 
exception. 


r  h  expri  ^  expi  :  coni  T  h  expr2  ^  exp2  :  con2 
r  h  coni  =  con2  :  O  F  hiq  coni  s^P 
F  h  expri  ~  ^xpi^2  ^^P2)  • 


(189) 


Rule  189:  Translation  of  equality  comparison;  exp  is  the  equality  function  generated  by  the 
equality  compiler  and  has  type  conx  con— ^ Bool. 


6.6.2  Matches 


r  h  match  ^  exp  :  con 

var,  var'  ^  BV (F)  F  h  con' :  Q 
F  h  pat  var'  :  con'  else  6a5i5.fair.fail  sbnds  :  sdecs 
F,  l*\>var '.[sdecs]  h  expr  exp  :  con 

F  h  pat  =>  expr  ^  A(uar':con'):con.let  uar=[56nc?5]  in  exp  end  :  con'^con 

Rule  190:  The  result  of  translating  a  match  is  a  function  that  may  fail  if  the  match  fails.  The 
IL  let  expression  is  well-formed  because  the  pattern  compiler  returns  no  type  components  in 
sbnds. 


(190) 


var  ^  BV(r) 

F  h  mrule  ^  exp  :  coni— ^con2 
F  f-  match  exp'  :  con'i^con'2 
F  h  coni— ^con2  =  con'i-^con'2  : 

F  h  mrule  I  match  A(t;ar:coni):con2.catch^‘’"  exp  uorwith  exp'  var  :  con'-^con 


(191) 


Rule  191:  The  failure  of  pattern  matching  in  the  first  clause  is  caught,  and  we  try  again  with 
the  next  clause. 
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6.6.3  Declarations 


r  h  strdec  ^  sbnds  :  sdecs 


var  ^  BV(r) 
r  h  errpr  ex'p  :  con 


r,  vav'.con  h  pat  ^  var  :  con  else  6as*5.Bind  .Bind  s6nc?5  :  sdecs 
r  h  val  0  pat  =  expr  l>war=ea;p,  sfends  :  li>?;ar:con,  sdecs 

Rule  192:  Monomorphic,  non-recursive  variable  bindings. 


(192) 


sipp  —  [{eq)ityvari  :[{eq)ityvari>var:Q,{,eq:varxvar~^Boo\)i],  •  •  • , 
{eq)ntyvarJ‘:[{eq)ntyvarn>var:Q,,{,Q(l'-varxvar^Boo\)n], 
l*:[l>war:r2(, eq:r;arx?;ar— ^Bool)i/],  •  •  • , 
m*  :[m>var:Cl{,  eq:  nor  x  oar —^Bool),„']] 
r,  l*>varp:sigp  h  expr  exp  :  con 
r,  l*>varp:sigp  h  exp  4-  con 

r,  l*>narp;s^^p  f-  6osis.Bind*.Bind  4=  exp  :  con  else  pat  ^  sbndi, sbndn 
Vi  G  l..n  : 

sbndi  =  labi=expi 

sdeCi  ~~  iabiiCorhi 

labi—{varp:sigp)^[it—expj]  if  F,  varp'-sig^  h  sbndi  J,  sdeCi 
labi=expi  if  r  h  expi  :  coni 

labi:{varp:sigp)->[it:coni]  if  F,  varpisipp  h  sbndi  I  sdeCi 
lab  f  coni  if  F  h  expi  :  coni 

F  h  val  ({eq)ityvar^,  •  •  • ,  {eq)ntyvar^)  pat  =  expr 
sbnd'i, . . . ,  sbnd'j^  :  sdec[, . . . ,  sdec'^ 


sdeci^ . . .  ^  sdeCji 


(193) 


Rule  193:  Polymorphic,  non-recursive  val  bindings.  We  assume  a  prepass  which  annotates 
val  declarations  with  the  explicit  type  variables  implicitly  scoped  by  that  declaration.  Type 
inference  may  introduce  m  new  type  (or  equality  type)  variables  which  not  mentioned  in  the 
source  (as  in  val  f  =  fn  x  =>  x  or  val  f  =  fn  x  =>  (x=x)).  In  this  formulation,  some 
variables  in  the  pattern  may  become  polymorphic  while  others  may  remain  monomorphic. 
Therefore,  for  each  z,  either  sbnd[  and  sdec[  must  both  choose  the  first  option  (polymorphic) 
or  must  both  choose  the  second  option  (monomorphic). 


45 


siQp  =  [{eq)ityvari-.[{eq)ityvari>var:fl{,eq:varxvar^Boo\)i],  •  •  • , 
{eq)mtyvcirJ:[{eq)mtyvar^>var:Q{,  eq:?;flr x  uar^Bool);,!] 

1* : [l>?;ar (,  eq: war xuar—^ Bool)  1/],  •  •  • , 
k*:[k>var:Q.{,eq:varxvar^Boo\)k']] 
r'  =  r,  lab*>varp:sigp,  idi>var[:coni-^con[,  •  •  • ,  idn>var'^:conn^con'^ 

Vi  G  l..n  : 

r'  h  matchi  \{vari\coni)\con'i.expi  :  coni-^con[ 

If  r  l^tx  idi  path"  :  con"  then  path" .expose,  path" .tag  aren’t  well-formed. 
exp  =  fix  var[{vari: coni): con[y-¥ exp i,  •  •  • ,  var[,^{varm-conm)'Con'.^\-^exp.^  end 

r  h  val  (.{eq)ityvari,  •  •  • ,  {eq)mty'uar^  rec  {{labi=idi)f-i}  =  {(/a6j=fn 
idi—Xvarp:sigp.[it=7ri  exp], . . . ,  idn=Xvarp:sigp.[it=Trn  exp]  : 
idi:{varp:sig  )—^[it:coni—^con[], . ..,  idn:{varp:sigp)—>[it:conn-^con'.^] 

(194) 

Rule  194:  This  rule  handles  recursive  val  bindings.  As  in  Rule  193,  we  assume  that  the  implicit 
scoping  of  explicit  type  variables  has  been  made  explicit  by  a  prepass  over  the  EL.  We  also 
assume  that  val  rec  ...  and  ...  is  syntactic  sugar  for  a  single  val  rec  binding  of  a  record 
of  functions.  Since  this  rule  does  not  use  the  pattern  compiler,  we  must  explicitly  check  that 
we’re  do  not  redefine  datatype  or  exception  constructors. 

r  h  strdeci  sbndsi  :  sdecsi 

r,  sdecsi  h  strdec2  sbnds2  :  sdecs2  (195) 

r  h  strdeci  strdec2  sbndsi++sbnds2  :  sdecsi++sdecs2 

Rule  195:  We  use  the  syntactic-concatenation-with-renaming  operation  defined  in  Section  6.2. 


Vi  G  l..n  :  r  f^tx  longstridi  path^  :  sig^^ 

r  h  open  longstridi  •  •  ■  longstrid,,^ 

l*=pathi,  •  ■  ■ ,  n*=pathj^  :  l*:sigi,  •  ■  ■ ,  n*:sig.^ 

T  ty  con  :  var  ^  BV(r) 

r  h  exception  id  of  ty 

ic?*=[tag>t;ar=new_tag[con],  id—X{var':con):Tagged.tag{var,  var')]  : 
id* :  [tag>?;ar :  con  Tag,  id:  con— ^-Tagged] 


r  h  exception  id 

id*=[tag>t;ar=new_tag[Unit],  id=tag{var,  {})]  : 
id*:[tag>t;ar:UnitTag,  id:Tagged] 

r  htx  longid  ^  path. lab  :  con 
r  h  path.tag  :  con' 

r  h  exception  id  =  longid  ^ 

id* =[tag=path. tag,  id=path. lab]  :  id  :[tag:con',  idtcon] 


(196) 


(197) 


(198) 


(199) 
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Rule  199:  Structures  containing  a  “tag”  component  are  created  by  EL  exception  declrations 
only. 


var  i  BV(r) 

r  h  strdeci  sbndsi  :  sdecsi 
r,  l*>var'.[sdecs-i\  h  strdec'  ^  sbnds2  :  sdecs2 

r  h  local  strdec  in  strdec'  end  ^ 

l>var=[sbndsi\,  sbnds2  :  l>var:[sdecsi],  sdecs2 


(200) 


Rule  200:  We  create  bindings  for  all  of  the  declarations,  but  the  local  bindings  are  segregated 
into  a  substructure  inaccessible  from  the  EL. 


r  h  tybind  sbnds  :  sdecs 
r  h  type  tybind  sbnds  :  sdecs 


(201) 


r  l^tx  longtycon  path. ty con  : 

r  h  path  :  [tycon^variCf^^Cl,  labi>deci,  •  •  • ,  Za6„i>dec„] 
labn  =  expose 


r  h  datatype  (tyvar-^ .  •  •  •  •  tyvar.^^)  tycon' 

=  datatype  ityvari,  ,tyvar.^)  longtycon 


(202) 


tycon'* —[tycon'>var=path.tycon,  labi^path.labi,  •  •  • ,  labn=path.labn]  '■ 
tycon'* =\tycon'\>var’.Q!^=^Vt=path.tycon,  labi=deci,  •  •  • ,  labn=deCn\ 


Rule  202:  SML  ’96  adds  the  ability  to  copy  datatypes.  Only  structures  which  are  the  transla¬ 
tions  of  EL  datatype  declarations  have  an  initial  type  component  and  a  final  component  named 
“expose” . 


r  h  datbind  sbnds  :  sdecs 
r  H  datatype  datbind  sbnds  :  sdecs 

r  h  strbind  sbnds  :  sdecs 
r  h  structure  strbind  sbnds  :  sdecs 

r  h  funbind  sbnds  :  sdecs 
r  h  functor  funbind  sbnds  :  sdecs 

6.6.4  Structure  Expressions 


r  h  strexp  mod  :  sig 

r  l^tx  longstrid  path  :  sig 

(206) 

r  h  longstrid  ^  path  :  sig 

r  h  strdec  sbnds  :  sdecs 

_  (9.07^ 

r  h  struct  strdec  end  ^  sbnds  :  sdecs 

(203) 

(204) 

(205) 
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r  f^tx  longfunid  ^  path^  :  (uari:si^i)— 
r  f^tx  longstrid  path  :  sig 
r  liub  po-ih  :  sig  ^  sig^  ^  mod  :  sig' 

T  h  {vari:sig)-^sig2  =  sig'-^sig"  :  Sig 
r  h  longfunid  {longstrid)  ^  {path f : sig' ^ sig")  mod  :  sig" 

Rule  208:  We  insert  an  explicit  coercion  to  drop  and  reorder  components  of  the  argument 
structure  (which  has  signature  sig),  in  order  to  match  the  domain  signature  of  the  functor 
{sigi).  The  signature  sig'  is  the  most-specific  (and  fully  transparent)  signature  of  the  coerced 
structure,  which  may  expose  more  types  (is  a  sub-signature  of)  sig^^. 


r  f^tx  longstrid  path  :  sig  F  h  sigexp  sig' :  Sig 
r  fiub  path  :  sig  sig'  mod  :  sig" 

r  h  longstrid  :  sigexp  mod  :  sig" 


(209) 


Rule  209:  As  in  SML,  ascribing  a  signature  to  a  structure  using  hides  components  (this 
hiding  being  accomplished  here  via  an  explicit  coercion),  but  allows  the  identity  of  the  remain¬ 
ing  type  components  to  leak  through.  The  rules  for  coercions  ensure  that  sig"  will  be  fully 
transparent,  maximizing  propagation  of  type  information. 


r  f^tx  longstrid  path  :  sig  F  h  sigexp  sig' :  Sig 
F  fiub  :  sig  ^  sig'  ^  mod  :  sig" 

F  h  longstrid  :  sigexp  {mod:sig')  :  sig' 


(210) 


Rule  210:  Ascribing  a  signature  to  a  structure  with  ;  >  not  only  hides  components,  but  restricts 
information  about  types  to  that  which  appears  in  the  signature. 


var  ^  BV(F) 

F  h  strdec  sbnds  :  sdecs 
F,  [screes]  h  strexp  mod  :  sig 

F  h  let  strdec  in  strexp  end 

[lt>var=[sbnds],2*=mod]  :  [lt>var-.\sdecs\,2*:sig\ 


(211) 


6.6.5  Structure  Bindings 

r  h  strbind  ^  sbnds  :  sdecs 


F  h  strexpi  modi  ■  sipi  (•  •  •  F  h  strexp^  mod^  :  sig,,) 

F  f-  stridi  =  strexpi  (and  •  •  •  and  stridn  =  strexp^f)  _ 

stridi—modi{,  •  •  • ,  stridn— mod^)  '■  stridi:sig-^{,  •  •  • ,  stridn-sipn) 


(212) 
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6.6.6  Functor  Bindings 


r  h  funbind  sbnds  :  sdecs 


var  ^  BV(r) 

r  h  sigexpi  sig^  :  Sig  F,  strict i>var:sigi  h  strexp^  modi  '■  sig[ 

(:) 

(F  h  sigexpn  ^  sig^  :  Sig  F,  stridn>var:sign  h  strexp^  modn  :  sig'^^) 

F  \-  funidiistridi  :  sigexp-^)  =  strexp^ 

(and  •  •  •  and  funidnistridn  '■  sigexpi)  =  strexp^) 

{funidi=Xvar:sigi.modi:var:sigi—^sig'i)'i-i  : 
{fumd-^:var:sig^-^sig[)^^i 

Rule  213:  As  for  functions  at  the  expression  level,  user-defined  functors  are  given  partial  functor 
types. 


6.6.7  Specifications 


Fh  • 

TV(fy)  =  0 

T  \-  ty  con  : 

F  h  val  id  :  ty  id:con 


r  h  spec  sdecs 

(214) 

(215) 


Rule  215:  A  value  specifiation  is  monomorphic  if  the  EL  type  contains  no  type  variables.  (The 
set  of  type  variables  of  the  EL  type  ty  is  denoted  by  TV(tj/).) 


TYjty)  =  {{eq)ityvar^,  •  •  • ,  {eq)ntyvar^}  0 
sipp  =  [{eq)ityvari  •\{eq)ityvari\>var:Q,{,QC];.varxvar-^Boo\)i],  •  ■  ■ , 
{eq)ntyvar^  :[{eq)ntyvarn>var:Q,{,eq:varxvar-^Boo\)n]] 

F,  lab*>var:sigp  h  %  con  :  Q 

F  h  val  id  :  ty  ^  id-.{var-.sigp)-^[it:con] 

Rule  216:  Specification  of  a  polymorphic  value. 

F  h  typdesc  ~s-  sdecs 
F  h  type  typdesc  sdecs 

F  h  etypdesc  sdecs 
F  f-  eqtype  etypdesc  sdecs 

r  ty  con  :  f2 

F  h  exception  id  of  ty  id:  [tag:  con  Tag,  id:con— ^Tagged] 


(216) 


(217) 

(218) 
(219) 
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(220) 


r  h  exception  id  id:  [tag:  con  Tag,  id:Tagged] 
r  h  datbind  sbnd  :  l*:[5decs] 
r  h  datatype  datbind  sdecs 


r  hjtx  longtycon  ^  path. ty con  : 
r  h  path  :  [tycon:Q,'^=>Q,,  sdecs] 


r  h  datatype  (.tyvar^ ,  ■  ■  •  ,  tyvar^)  tycon' 

=  datatype  (.tyvavi,  •••  .tyvar^^')  longtycon 
tycon'* ■.[tycon'>var:Q.‘^^n—path.tycon,  sdecs] 


r  h  sigexp  sig  :  Sig 
r  h  structure  strid  :  sigexp  strid'.sig 


r  h  sigexp  sig  :  Sig 
var  ^  BV(r) 

r,  stridt>var:sig  h  sigexp'  sig'  :  Sig 
r  h  functor /nnid  {strid  :  sigexp)  :  sigexp' funid:{var:sig-^sig') 

r  h  sigexp  [sdecs]  :  Sig 
r  h  include  sigexp  sdecs 


(221) 

(222) 

(223) 

(224) 

(225) 


r  h  speci  sdecsi  F,  sdecsi  h  spec2  sdecs2 
r  h  sdecsi,  sdecs2  ok 
r  h  speci  spec2  sdecsi,  sdecs2 


(226) 


Rule  226:  We  disallow  redeclaring  EL  identifiers  in  a  signature.  In  the  presence  of  include, 
we  cannot  syntactically  restrict  the  EL  to  guarantee  the  syntactic  concatenation  of  sdecsi  and 
sdecs2  will  be  well-formed. 


r  h  spec  ^  sig  :  Sig 
var  i  BV(r) 

F;  var'.sig  f^jg  longidi  labsi  :  knd 
F;  var'.sig  fiig  longid2  labs2 '  knd 
F,  var'.sig  h  var.labsi  =  var.labs'i  :  knd 
F,  var'.sig  h  var.labs2  =  var.labs'2  :  knd 
sig  lih  labs'i  labs'2  :  knd  sig'  :  Sig 
or 

sig  hih  labs'2  •=  labs'^  :  knd  sig'  :  Sig 
F  h  spec  sharing  type  longidi  ~  longid2  sig'  :  Sig 


(227) 


Rule  227:  A  type  component  in  a  signature  is  considered  abstract,  and  hence  eligible  to  appear 
in  a  sharing  constraint,  if  it  is  equivalent  to  an  opaque  type  (type  component  that  is  not  a  type 
abbreviation)  in  the  spec. 

We  find  the  two  opaque  types  to  which  the  given  components  are  equivalent,  and  patch  the 
signature  such  that  the  opaque  type  with  the  smaller  scope  becomes  a  type  abbreviation  for 
the  other  opaque  type. 
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6.6.8  Signature  Expressions 


r  h  sigexp  sig  :  Sig 


r  h  spec  ^  sig  :  Sig 
r  h  sig  spec  end  ^  sig  :  Sig 


(228) 


var,  vari,  •  •  • ,  uar„  ^  BV(r) 
r  h  sigexp  sig  :  Sig 

r,  •  •  • ,  tyvarji>varn'.0,  \-  ty  con  :  ^2 

F;  vav.sig  fiig  longtycon  labs  :  f2"=^Q 
r,  var'.sig  h  var. labs  =  var. labs' :  r2”=^f2 
sig  livt  labs'  :=  A(uari,  •  •  • ,  varn)-con  :  sig'  :  Sig 

r  h  sigexp  where  type  {tyvari ,  •  •  ■  ,tyvar.^)  longtycon  -  ty  ^  sig'  :  Sig 

Rule  229:  Note  that  type  EL  type  expression  ty  is  evaluated  using  the  ambient  scope. 


(229) 


6.6.9  Type  Expressions 


r  h  int  Int : 


T  \-  ty  con  :  Q 
(230) 


Rule  230:  There  are  analogous  rules  for  the  other  base  types  (Float,  Bool,  Unit,  String,  and  so 
on),  and  the  base  type  constructors  (ref). 


F  h  exn  Tagged  :  12 

(231) 

F  hjtx  tyvar  path  :  12 

(232) 

F  h  tyvar  path  :  12 

r  tyi^  coni  :Vt  •  •  •  F  h  con„  :  Q, 

a  a  permutation  of  l..n 

<•••<!  lab(^(ji^ 

F  h  ilabi  :tyi,---,  labn :  ty^}  ^  {lab„(^i):cona(i),  •  •  • ,  (o6^(„):con(^(n)}  :  12 

F  l^tx  longtycon  path  :  12"=^  12 
Vi  e  l..n  :  F  h  2t/j  coni  '•  12 
r  \-  (tyi,  •  ■  ■  ,  ty.^)  longtycon  path  {coni,  •  •  • ,  con„)  ;  12 

F  h  2y  ^  con  :  12  T  \-  ty'  con'  :  12 
r  ty  ->  ty'  con-^con'  :  12 

Rule  235:  There  is  no  way  to  express  total  (->)  types  in  the  external  language. 


(233) 


(234) 

(235) 
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6.6.10  Type  Definitions 


r  f-  tybind  shnds  :  sdecs 


vari,“-,varn^BY{r) 

r,  tyvar^ovari.Q,  ■  ■  ■ ,  tyvar^>varn-^  ty  con'  :  Q 
con  =  \{vari,  •  •  • ,  varn)-con' 

(r  h  tybind  sbnds  :  sdecs  var  ^  FY {sdecs)) 

r  I-  ityvar^ ,  ■■■  ,tyvar„)  tycon  =  ty  (and  tybind) 

tycont>var=con{,  sbnds)  :  tycon>var\QP'^VL—con{,  sdecs) 


(236) 


6.6.11  Type  Descriptions 


(r  h  typdesc  sdecs) 

r  h  type  (tyvari,  •  •  • ,  tyvarji)  id  (  and  typdesc) 


r  h  typdesc  [sdecs] 


id:Q,'^=^Q{,  sdecs) 


(237) 


vari,  •  •  • ,  vavn  ^  BV (F) 

r,  tyvari>vari:^,  •  •  • ,  i?/uar„>var„:f2  F  ty  con'  :  O 
con  :=  X{vari,  •  •  • ,  varn)-con' 

(r  h  typdesc  sdecs  var  ^  FY  sdecs)  (238) 

r  I-  type  ityvar^,  •  •  • ,  tyvar^)  id  =  ty  ((  and  typdesc))  id:QP=^€t—con{,  sdecs) 


6.6.12  Equality  Type  Descriptions 


r  h  etypdesc  ^  sdecs 


The  polymorphic  equality  functions  defined  by  this  judgment  the  same  as  the  default  “struc¬ 
tural”  equality  supplied  by  SML.  EssentiallyFa  type  is  an  equality  type  if  and  only  if  we  can 
use  this  judgment  to  create  the  equality  function  at  that  type. 

sig'  =  [tyvarl* :[tyvari>vari:Q,,  eq:variXvari-^Boo\\,  •  •  • , 
tyvar^  ;[tywar„>war„:Q,  eq:uor„xt;ar^Bool]]_ 
con  =  var{var' .tyvavi* .tyvari,  •  •  • ,  var' .tyvar .tyvar 

(r  h  etypdesc  sdecs)  (239) 

r  h  {tyvari,  •  •  • ,  tyvarj  id  (and  etypdesc) 

Id* :[idt>var:Fl'"'=>Q,,  eq:{var' :sig')^[it:conx  con-^Boo\]]{,  sdecs) 


6.6.13  Datatype  Definitions 


r  h  datbind  sbnds  :  sdecs 


Without  loss  of  generalityFwe  may  assume  that  there  are  no  duplicate  tyvar’s  among  the 
bindings. 
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r'  ;=  r,  tyconi>varf^:Q'^^=^0.  ,  tyconp>varp^:Q,^’’=^Q, 
r"  :=  r',  tyvar^^>varn tyvaVp^^varpn^:^, 
vari, . . . ,  varn  ^  BV(r") 


unit  j 

r"  h  <  or  coUij  :  Q 

.  ^Vij  )  ij 

conf^^  :—  Ti(^idiiy->conii,  •  •  • ,  idimi^coriijn^ 

con\  :=  TTi  A(uarf , . . . ,  varf).{{\{varji, . . . ,  varjn^).  conf'^Y^^^)) 

coui  :=  con[  {varn, ... ,  varim) 

(r'  kq  V(t;arii, . . . ,  varini).coni  ).expY)i' 

modi  ;=  [tycorij^varf—con'i, 

{eq=A{var^^'^^'^^' ,...,  var^^^^'"'^').expY)i’ 

(  roll--  (injg"-  {})  I 

idij=A{varii, ...,  uari„J.  <  or  >  , 

yX{var:conij):coni.ro\\  ?;ar)j 

expose=A(?;arii, . . . ,  varini).X{var:coni):conY’^.unro\\  var]  :  sipi 

sipi  :=  [tyconi>vari:Q'^^  =^iQ,=varf , 

(eq:V(uar-i^^‘‘^^' , . . . ,  var-^^^‘’-’').yarjXt;ari-^Bool)i', 


,  (for  j  e  l..mi) 


idij-X^{varii, ...,  varim). 


coriij—^coni 


,  (for  j  e  l..mi) 


expose:V(i;arji, . . . ,  uarjnj.conj^conf"™]  _  _ ^ 

mod  :=  [tyconit>varf=con[,  ■  ■  ■ ,  tyconpt>varf=con'p,  ty con i*= modi,  ■  ■  ■ ,  tycoUp* =modp] 
sip  :=  [tycon.^\>varf:9P'^^Vt, . . . ,  tyconp>varf-.QP'^^Q,,  tyconY-siPi,  ■  ■  ■ ,  tyconp*:sipp\ 


r  h  (iyuarii,  •  •  •  i?/coni=  ic?ii<  or  >  I  •  •  •  U'c?imi  <  or  > 

and  ■ • • and 


ityvaTpi  ,  ■  ■  • ,  tyvaVpnY  tyconp=idpi  <  or  >  I  •  •  •  I  idpm^  <  or 

\  of  tPpi  J  of  tppjp^ 

l*={mod:sip)  :  l*:sip 


or  > 


(240) 
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6.7  Polymorphic  Instantiation 


decs  [sbndsy]  :  [sdecs'] 


decs  h  con  : 

{decs  Fiq  con  expy) 

{{decs  finst'^  [sbndsy]  :  [sdecs])) 

decs  Ijnst'^  [lab'-[lab>var—con{,eq=expy)]{{,sbndSy))]  : 

[lab':[lab>var:Q.=  con{,eq:varxvar-^Boo\)]]{{,  sdecs)) 


(241) 


Rule  241  Nondeterministically  choose  types  and  the  corresponding  equality  functions  so  as  to 
match  a  fully-transparent  signature. 


6.8  Equality  Compilation 

decs  l^q  con  exp 


decs  liq  Int^  A(wari:lnt,  t;ar2:lnt:).Bool(t;ari  =int  var2) 


(242) 


Rule  242:  We  assume  primitive  equality  operations  already  exist  at  type  Int,  with  similar  rules 
for  the  other  base  types. 


con  =  {/a6i:coni, . . . ,  labn-conn} 
decs  l;iq  coni  expi  ■  ■  ■  decs  f^q  con„  ^  ex/)„ 

decs  fgq  con 

X{vari:con,var2:con):Boo\.expi  {iriabi  vari,7riabi  mr2)and 

•  •  •  and  expn  {TTiabn  vari,'Kiabn  ^0x2) 


(243) 


Rule  243:  Records  are  compared  component-wise  for  equality. 


Vz  e  l..n  :  confab)  ■=  ^{lu)  {coni, conn) 

(  decs  liq  coni  ^  expi 

_ \  exp’i  =  Xvar':coniab,.expi  {proi'j^l  var',  pproj^’^"  {var2, )) _ 

decs  iiq  con 

X{vari:con,  mr2;con):Bool.catch  case"’"  vari  ofexp'i, exp'^  end  with  false 


(244) 


Rule  244:  Values  of  a  sum  type  are  equal  if  they  have  the  same  tag  and  the  tagged  values  are 
equal. 
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sig' 


k  e  l..n 

/ 

(  corii  =  {-Ki  {ii  con'))  con" 

%  e  ..n  .  I  con" 

decs'  =  decs,  uari:[l>vor’:f2=coni,eq:i/arxuar-^Bool], . . . , 
vavn ■  [l>var :  conn,  eq:  var  x  t;ar—^ Bool] 

decs'  liq  Unroll  con]  exp^ 

Vz  e  l..n  :  <  expf^  =  ({nari'^/nar'i-eq}  •  •  •  {var^^/var'^.eq}expi) 

(unroll  {nivar),  unroll  {v^var)) 


decs  hgq  conk  ^  f\x{varf^ {var :coniX coni) :Boo\t-^ exp endvar) 
Rule  245:  A  recursive  type  generates  recursively-defined  equality  functions. 


,eq 


(245) 


decs  h  path.eq  :  path. lab  x path. lab -^Boo\ 
decs  l^q  path. lab  path.eq 


(246) 


Rule  246:  If  the  constructor  is  simply  a  path— the  name  of  an  abstract  type— we  look  for  an 
equality  function  for  that  type  in  the  same  structure. 


con  =  path. lab  (coni, . . . ,  conn) 
decs  finst"^  modp  :  sig^ 
decs  h  path.eq  :  sz^p->[it:conxcon— ^Bool] 

decs  hiq  con^  {path. eq{modv)). it 


(247) 


Rule  247:  Same  as  Rule  246,  except  here  we  deal  with  the  application  of  an  abstract  type  to 
a  tuple  of  types.  The  instantiation  judgment  may  recursively  invoke  the  equality  compiler,  in 
order  to  create  equality  functions  for  coni,. . . ,  con„. 


decs  h  con  =  con'  : 
decs  liq  con'  exp 

decs  liq  con  exp 


(248) 


decs  fiq  sig  mod 


■■=  [1 


sig  =  [r:[l>nari:n], . . .  ,n*:[n>varn:^]] 

*:[l>uari:fi(,  eq:?;ariXt;ori-^Bool)i], . . .  ,n*:[n>nar„:f2(,eq:?;flr„xmrn 

decs,  var:sig'  f^q  con  exp 
decs  f^q  var\sig->[it:con]  Xvar : sig' .[it= exp] 


Bool)n]] 


(249) 
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6.9  Pattern  Compilation 


Patterns 


r  h  pat  exp  :  con  else  exp'  ^  sbnds  :  sdecs 


The  judgment  should  be  read  as  “the  bindings  of  the  result  of  matching  exp  to  the  pattern  pat 
are  sbnds.” 


Rules  255r257rand  259  do  not  apply, 
r  h  exp  :  con 

T  [-  id  <=  exp  :  con  else  exp'  id=exp  :  id:  con 


(250) 


Rule  250:  Pattern  match  against  an  variable  (which  is  not  a  datatype  or  exception  constructor). 


lab  fresh  type(5con)  =  con 
r  h  exp  :  con 

r  h  scon  4=  exp  :  con  else  exp' 

/o6=ife2;p=corascon  then  {}  else  raise exp'  :  lab:i)mt 


(251) 


Rule  251:  Pattern  match  against  a  constant.  We  need  primitive  equality  functions  for  constants 
which  can  appear  in  patterns. 


lab  fresh  F  h  exp  :  con 
r  h  _  exp  :  con  else  exp'  lab— exp  :  lab:con 

Rule  252:  Pattern  match  against  a  wildcard. 


(252) 


F  \~  ty  con'  :  T  h  con  =  con'  :  Fl 

F  h  pat  <=  exp  :  con  else  exp'  sbnds  :  sdecs 

F  h  pat  :  ty  <=  exp  :  con  else  exp'  sbnds  :  sdecs 
Rule  253:  Pattern  match  against  an  explicitly-typed  pattern. 


(253) 


r  Ijtx  longid  path.labi  :  coni— ¥  con 
F  h  path.expose  :  con-^'E{labi^coni, . . . ,  labn^conn) 
r  h  pa^  <t=  {{path.expose  exp),  exp')  :  coui  else  exp'  ^  sbnds  :  sdecs 

F  h  lonqid  pat  <^=  exp  :  con  else  exp'  sbnds  :  sdecs 

(254) 


Rule  254:  Pattern  match  against  a  monomorphic  datatype  constructor  which  carries  a  value. 
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(255) 


r  h3tx  longid  path .  labj  :  con  lab  fresh 
r  h  exp  :  con 

r  h  path.expose  :  con— >Ti{labi^ coni,  •  •  •  >  labn'-^conn) 
r  h  longid  <=  exp  :  con  else  exp' 

{{path.expose  exp),  exp')  :  lab:\Jn\t 

Rule  255:  Pattern  match  against  a  constant,  monomorphic  datatype  constructor. 


r  l^tx  longid  path. lab i  :  sig 

T  t-  path.expose  :  sigp—>[it:con—^T,{labi)-^coni, . . .,  /a6„i-4con„)] 

r  h'nst'^  modp  :  sipp 

T\-pat-^  pp^^j^/a6ih4coni,...,Jai.n'^con„)  (^(^(^p^fh .expose  THodp) .it  exp) ,  exp')  :  coni  else  exp' 
sbnds  :  sdecs 

r  h  lonqid  pat  <=  exp  :  con  else  exp'  sbnds  :  sdecs 

^  (256) 


Rule  256:  Pattern  match  against  a  polymorphic  datatype  constructor  carrying  a  value. 


r  Ijtx  longid  path.labi  :  sig 
r  h  exp  :  con 

r  h  paf/i. expose  :  >[it: con— >-E(/a6ii->-coni, . . . ,  /a?)„i->con„)] 

r  hiist'^  modp  :  sipp  lab  fresh 

r  h  longid  4=  exp  :  con  else  exp'  ^ 

{{path.exposemodp).itexp,exp')  :  /a6:Unit 
Rule  257:  Pattern  match  against  a  constant  polymorphic  constructor. 


(257) 


r  h3tx  longid  path. lab  :  con— ^Tagged 

r  h  path.tSig  :  con  Tag 

r\-  pat  ^  (iftagof  exp  ispai/i.tagthen  Anaricon. war  else  raise"”  exp')  else  exp' ^ 

sbnds  :  sdecs  _ 

r  h  longid  pat  4=  exp  :  con  else  exp'  sbnds  :  sdecs 

Rule  258:  Pattern  match  against  value-carrying  exception  constructor. 


(258) 


r  l^tx  longid  path.lab  :  Tagged  lab  fresh 
r  h  exp  :  con 
r  h  pai/i.tag  :  Unit  Tag 

r  h  longid  4=  exp  :  con  else  exp' 

/o6=iftagof  exp  ispai/i.tagthen  Awar:Unit.{}  else  raise^"'*  exp'  :  /a6:Unit 


(259) 
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Rule  259:  Pattern  match  against  constant  exception  constructor. 


r  h  con  =  {lab\:con'i,  •  •  • ,  lah'j^'.con'^}  :  Q, 

{lahi,  •  •  • ,  lahn]  C  {lah'^,  •  •  • ,  lah'^} 

Vt  e  l..n  :  r,  lab\>var\con  pati  <=  Tr^^exp  :  coui  else  exp'  ^  sbndsi  :  sdecsi 

r  h  ilabi  =  pati, . . labn  =  pat^i, . . .)}  <^  exp  :  con  else  exp' 
sbndsi, . . . ,  sbndsn  '■  sdecsi, . . . ,  sdecsn 

Rule  260:  Pattern  match  against  a  record  of  patterns.  Because  we  disallow  repeated  variables 
in  patterns,  the  syntactic  concatenation  of  structure  here  is  well-formed. 


r  h  pat^  <=  exp  :  con  else  exp'  sbnds\  :  sdecsi 
r  h  pat2  exp  :  con  else  exp'  ^  sbnds2  :  sdecs^ 

r  h  pati  as  pat2  ^  exp  :  con  else  exp'  sbndsi,  sbnds2  '■  sdecsi,  sdecs2 

Rule  261:  Pattern  match  against  two  patterns  simultaneously. 


(261) 


r  h  pat  <=  get  exp  :  con  else  exp'  sbnds  :  sdecs 
r  h  ref  pat  4=  exp  :  con  Ref  else  exp'  sbnds  :  sdecs 

Rule  262:  Pattern  match  involving  implicit  dereferencing  of  a  ref  cell. 


r  h  pat  <=  exp  :  con'  else  exp'  sbnds  :  sdecs 
r  h  con  =  con'  :  Q, 

r  h  pat  4=  exp  :  con  else  exp'  sbnds  :  sdecs 


(262) 


(263) 
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6.10  Coercion  Compilation 


decs',  path: sigo  hgub  sdec^  shnd  :  sdec 


decs',  varo'.sigQ  ^jjg  lab  ^  labs  :  con' _ 

lab>var=varo.labs  :  lab>var:con 


r 


decs]  path: sig^  fiub  lab>var:con  -  ^ -  - 

Rule  264:  Coercion  of  a  monoraorphic  value  specification  to  a  monomorphic  value  specification 


(264) 


decs]  varo'.sigQ  fjjg  lab'^  labs  :  con-^con' _ 

decs]  path'.sigo  Ub  lab>var:con-^con'  ^  lab>var=d  varo.labs  :  lab>var:con-^con' 


(265) 


decs,  var'p'.sig'p]  varo'.sigQ  liig  lab  labs  :  sigp-^[it:con\ 
decs,  var'p'.sig'p,  varo'.sigQ  modp  :  sigp 

decs]  path'.sigo  fiub  labt>var:{var'p:sig'p)-^[it:con] 
lab>var—\var'p'.sig'p.{varo.labs  modp)  : 
lab>var :  ( var'p :  sig'p)—¥  [it :  con] 

Rule  266:  Coercion  of  a  polymorphic  value  specification  to  a  polymorphic  value  specification; 
this  may  involve  implicit  polymorphic  instantiation.  (The  rule  also  handles  matching  polymor¬ 
phic  datatype  constructors  to  val  specifications.)  Note  that  sigp  and  sig'p  need  not  have  the 
same  labels,  so  this  rule  also  handles  alpha-conversion  of  EL  type  variables. 


decs,  var'p'.sig'p]  varo'.sigQ  fiig  lab  labs  :  sigp^[it:con^con'] 
decs,  var'p'.sig'p,  varo'.sigQ  frnst^  modp  :  sigp _ 

decs]  path'.sigo  fiub  lab>var:{var'p:sig'p)^[it:con-^con'] 
lab>var=Xvar'p:sig'p.[it—d{{varo.labs  modp).it)]  : 
lab>var:{var'p:sig'p)-^[it:con^con'] 


(267) 


decs]  varo'.sigQ  fijg  lab  labs  :  varp:sig^[it: con] 
decs  finst'^  'oiod  :  sig 

decs]  path'.sigo  fiub  lab>var'.con labt>var— (varo.labs  mod).it :  lab>var'.con 


(268) 


Rule  268:  Coercion  of  a  polymorphic  value  (or  datatype  constructor)  to  match  a  monomorphic 
value  specification. 


decs]  vavQ'.sigQ  lab  ^  labs  :  varp:sig—^[it:con—>con'] 
decs  linst"^  '^od  :  sig 

decs]  path'.sigQ  fiub  lab>var:con-^con'  lab>var-d  {{varo.labs  mod).it)  :  lab>var'.con 


—^con' 

(269) 


decs]  path'.sigQ 


decs]  varo'.sigQ  fiig  lab  labs  :  knd 
{decs,  varQ'.sigo  h  varQ.labs  =  con  :  knd) 
fiub  lab>var'.knd{—con)  lab>var— varQ.labs  :  lab>var:knd=varo.labs 

(270) 
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Rule  270:  Coercion  of  a  type  component  to  a  type  specification. 


decs]  varo'.sigQ  fiig  lab  labs  : 

{decs,  varo'.sigQ  h  varQ.labs  =  con  :  O) 
decs,  varo'.sigQ  liq  varo-labs  ^  exp 
decs]  path'.sigo  fiub  lab*'.[lab>var:Q{=con),eq:varxvar-^Boo\]'^ 
lab'*:[lab>var=varo.labs,  eq:exp]  : 
lab'*:[lab>var'.Q,=varo.labs,eq:varxvar-^Boo\] 

Coercion  of  a  type  declaration  corresponding  to  an  eqtype  signature  specification  involving 
no  type  variables.  We  invoke  the  equality  compiler  to  create  an  equality  function  for  the  type 
being  copied. 


decs]  varo'.sigQ  fiig  lab  labs  : 
con'  =  var{varp.lab'^.labi,  •  •  ■ ,  varp.lab'j^.labn) 
decs,  varo'.sigQ,  varfsigp  fiq  con'  exp 

decs]  path'.sigo  hgub  lab'* :[lab>var:Q.'''^Q.,eq:varp:sigp^[it: con' x  con' -^Boo\]]  ^ 
lab* '.[lab>var=varo. labs,  eq:Xvarp:sigp.[it=exp]]  : 

lab*  :[lab>var:Q,‘''=^Q,{=varo.labs),eq:varp:sigp^[it:con'x  con' -^Boo\]] 

Coercion  of  a  type  declaration  correspond  to  a  eqtype  signature  specification  involving  type 
variables  (i.e.,  eqtype  (’a,’b)  foo). 


decs]  varo'.sigQ  f^ig  lab  ^  labs  :  sig' 
decs,  varo'.sigQ  liub  path.labs  :  sig'  ■<  sig  mode  ■  sig^ 
decs]  path: sig Q  liub  lah>var:sig  ^  lab>var=modc  :  lah\>var:sig ^ 
Rule  273:  Coercion  of  a  module  component. 


(273) 


decs  fiub  path  :  sig^  sig  ^  mod  :  sig' 

decs]  path'.sigo  fiub  labi>deci  sbndi  :  sdeci 
decs,  deci]  path: sig Q  liub  Iab2>dec2  sbnd2  :  sdec2 


decs,  dec\, . . .,  deCn-i] path: sig q  liub  labn>decn  sbndn  ■  sdeCn 

decs  liub  path  :  sipo  :<  [labi>deci, . . . ,  labn>decn] 

[sbndi, .. .,  sbndn]  '■  [sdeci, . . .,  sdeCn] 

decs  liub  var2  ■  sig 2  sig  i^  mods  :  sig^ 

decs,  var2.sig2  liub  var'i  :  sig'i  sig'2  mod^  :  sig^ 
decs,  var2'.sig2  1“  mod^  :  sig 4^ 

decs  liub  path  :  {var i: sig i-^ sig'i)  {var2:sig2^sig'2) 

Xvar2:sig2.\&t:  var'i=path  mods  in  modi  end  : 
var2'.sig2^sig4 


(274) 


(275) 
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Rule  275:  Coercions  for  functor  subtyping.  We  also  need  the  same  rule  for  subtyping  of  total 
functors  (not  shown  here). 


6.11  Signature  Patching 

where  type  sig  labs  :=  con  i  knd  sig  :  Sig 

This  judgment  should  be  read  “By  adding  to  the  signature  sig  the  fact  that  the  abstract  type 
component  selected  by  labs  is  equal  to  con  ;  knd,  we  get  the  signature  sig  . 

FV(con)  n  BV(5(iec5)  =  0 
sig  =  [sdecs,  lab>var:knd,  sdecs'] 
sig  '■=  con  :  knd  [sdecs,  lab>var:knd=con,  sdecs']  :  Sig 

FV(con)  n  BV(sdecs)  =  0 
sig  =  [sdecs,  lab>var:sig' ,  sdecs'] 
sig'  labs  :=  con  :  knd  sig"  :  Sig 

sig  lab.labs  :=  con  :  knd  ^  [sdecs,  lab>var:sig" ,  sdecs']  :  Sig 
sharing  Fsh  Icibsi  lo,bs2  •  knd  sig  i  Sig 

This  judgment  should  be  read  “By  adding  to  the  signature  sig  the  fact  that  the  (abstract)  type 
components  of  kind  knd  selected  by  labs\  and  labs 2  are  equal,  we  get  the  signature  sig  . 


(276) 


(277) 


sig  =  [sdecs,  lab'>var'\knd,  sdecs',  lab>var:knd,  sdecs" _ 

sig  l^h  lab  :=  lab'  :  knd 

[sdecs,  lab'>var':knd,  sdecs',  lab>var:knd=var' ,  sdecs']  :  Sig 

sig  =  [sdecs,  lab'>var'-.knd,  sdecs',  lab>var:sig,  sdecs"] 
sig  labs  var'  :  knd  ^  sig'  :  Sig 

sig  lih  lab.labs  :=  lab'  :  knd 

[sdecs,  lab' t>var':knd,  sdecs',  lab>var:sig',  sdecs']  :  Sig 

sig  =  [sdecs,  lab'>var':sig',  sdecs',  lab>var:sig" ,  sdecs"] 
sig"  h^t  labs  var'. labs'  :  knd  sig'"  :  Sig 

sig  f^h  lab.labs  ;=  lab'. labs'  :  knd 

[sciecs,  lab'>var':sig' ,  sdecs',  lab>var:sig'" ,  sdecs"]  :  Sig 

sig  =  [sdecs,  lab>var:sig' ,  sdecs'] 
sig'  fih  labs  :=  labs'  :  knd  sig"  :  Sig 
sig  kh  lab.labs  :=  lab.labs'  :  knd  [sdecs,  lab>var:sig" ,  sdecs']  :  Sig 


(278) 


(279) 


(280) 


(281) 
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6.12  Lookup  Rules 

The  lookup  rules  specify  the  order  in  which  translation  contexts  and  IL  signatures  are 
searched. 

•  To  prevent  an  explosion  of  rulesTthe  metavariable  class  is  used  to  denote  a  typeF 
signatureTor  kind  as  appropriate. 

•  Any  IL  structure  label  starred  with  an  asterisk  {e.g.Tlab*)  is  treated  specially  by  the 
lookupFwhich  checks  inside  the  structure.  That  isFwhen  looking  for  an  identifier  in 
a  contextTwe  also  look  inside  starred  structure  declarations.  If  the  identifier  is  found 
inside  such  a  structureFthe  full  path  to  the  identifier  through  the  open  structure  is 
returned. 

•  Any  type  or  signature  returned  by  a  lookup  will  be  valid  with  respect  to  the  ambient 
context. 

6.12.1  Context  Lookup 

r  path  :  class 

Main  rules  for  looking  up  identifiers  in  a  translation  context. 


F  btx  labs  path  F  h  path  :  con 

F  l^tx  l(^bs  path  :  con 

F  f^tx  lo,bs  path  F  h  path  :  knd 

F  btx  lO'bs  path  :  knd 

F  f^tx  labs  path  F  h  path  :  sig 

F  l^tx  labs  path  :  sig 


(282) 

(283) 

(284) 


r  l^tx  la-bs  path 

“Utility”  rules  used  to  look  up  identifiers  in  a  translation  context. 


lab  =  lab' 

F,  lab>var:con  l^tx  lab'  var 

lab  lab'  F  i^tx  lab'  path 
F,  lab>var\con  i^tx  lab'  path 

lab  =  lab' 

F,  lab>var\knd{—con)  btx  lab'  var 

lab  ^  lab'  F  l^tx  lab'  ^  path 
F,  lab>var:knd{=con)  l^tx  lab'  path 


(285) 

(286) 

(287) 

(288) 
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(289) 


lab  —  lab' 

r,  lab>var:sig  lo,b'  var 

lab  ^  lab'  F  ^^b'  path 
r,  labt>var:sig  f^tx  lo-b'  path 

sig  fiig  lab'  path 
r,  lab*>var:sig  ^stx  loh'  var. path 

sig  fiig  lab'  F  f^tx  PO'ih 

F,  lab*>var:sig  hjtx  lo-b'  path 

F  [^tx  io,b  path  :  sig  r-,path:sig  fjjg  labs  ^  labs'  :  class 
F  l^tx  lab. labs  path. labs' 


(290) 

(291) 

(292) 

(293) 


6.12.2  Signature  Lookup 

decs]  path'. sig  liig  labs  ^  labs'  :  class 

Main  rules  for  looking  up  identifiers  in  a  signature. 


decs  h  sig  :  Sig  sig  Ijig  lab  labs'  decs  h  path. labs'  :  con 

decs;  pathisig  fiig  lab  labs'  :  con 

decs  h  sig  :  Sig  sig  ijig  lab  labs'  decs  h  path.labs  :  sig' 

decs]  path'.sig  f^ig  lab  labs'  :  sig' 

decs  h  sig  :  Sig  sig  igig  lab  labs'  decs  h  path.labs'  :  knd 

decs]  path'.sig  fiig  lab  labs'  :  knd 

decs  \-  sig  :  Sig 

decs]  path'.sig  fiig  lab  ^  labs'  :  sig' 
decs]  path.labs' :sig'  fiig  labs  labs"  :  class 
decs]  path'.sig  fiig  lab. labs labs'. labs"  :  class 


(294) 

(295) 

(296) 


(297) 


sig  fiig  lab  labs' 


“Utility”  rules  used  to  look  up  identifiers  in  a  signature. 


lab  =  lab' 

[sdecs,  lab>var:con]  fiig  lab'  lab 

lab  ^  lab'  \sdecs\  fiig  lab'  ^  labs 
[sdecs,  labpvar'.con]  fiig  lab'  labs 


(298) 

(299) 
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lab  =  lab' 

[sdecs,  lab>var:knd{=con)]  ^iig  lab'  ^  lab 

lab  ^  lab'  [sdecs]  l^jg  lab'  ^  labs 
[sdecs,  lab>var:knd{=con)]  f^jg  lab'  ^  labs 

lab  =  lab' 

[sdecs,  lab>var:sig]  fiig  lab'  lab 

lab  7^  lab'  [sdecs]  fiig  lab'  labs 
[sdecs,  lab>var:sig]  fiig  lab'  ^  labs 

sig  fiig  lab'  ^  labs 

[sdecs,  lab*>var:sig]  fiig  lab'  lab* .labs 

sig  fiig  lab'  [sdecs]  fiig  lab'  labs 

[sdecs,  lab*\>var\sig]  fiig  lab'  labs 


(300) 

(301) 

(302) 

(303) 

(304) 

(305) 


6.13  Overloading 

For  each  overloaded  identifier  we  wish  to  add  to  the  ELFwe  add  one  translation  rule  for  each 
overloaded  type.  For  exampleFwe  may  want  to  overload  the  EL  identifier  +  for  addition  at 
types  int  and  real.  In  this  caseFwe  would  add  two  rules  along  the  lines  of: 


r  h  +  •^  +int  :  Int  X  Int— ^Int 


and 

r  f-  +Fioat  :  Float  X  Float^Float’ 
where  +int  and  +Fioat  are  the  two  IL  primitive  addition  functions. 


7  Properties 

The  proofs  presented  here  are  only  sketches;  the  Standard  ML  language  is  far  too  large 
to  check  every  case  by  hand  in  a  reasonable  amount  of  time.  Future  work  may  involve 
attempting  to  check  these  proofs  with  an  automated  system. 

7.1  Properties  of  the  Internal  Language 

7.1.1  Static  Semantics 

Lemma  1  (Well-formedness) 

The  following  propositions  bold: 

1.  If  decs  f-  dec  ok  then  h  decs  ok. 
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2.  If  decs  h  bnd  :  dec  then  decs  h  dec  ok. 

3.  If  decs  h  knd  :  Kind  then  h  decs  ok. 

4.  If  decs  h  con  :  knd  then  decs  h  knd  :  Kind. 

5.  If  decs  h  con  =  con'  :  knd  then  decs  h  con  :  knd  and  decs  h  con'  :  knd. 

6.  If  decs  h  exp  :  con  then  decs  h  con  :  Q. 

7.  If  decs  h  sdecs  ok  then  h  decs  ok. 

8.  If  decs  h  sig  :  Sig  then  h  decs  ok. 

9.  If  decs  h  sdecs  <  sdecs'  then  decs  h  sdecs  ok  and  decs  h  sdecs'  ok. 

10.  If  decs  h  sig  <  sig'  :  Sig  then  decs  h  sig  :  Sig  and  decs  h  sig'  :  Sig. 

11.  If  decs  h  sdecs  =  sdecs'  then  decs  h  sdecs  ok  and  decs  h  sdecs'  ok. 

12.  If  decs  h  sig  =  sig'  :  Sig  then  decs  h  sig  :  Sig  and  decs  h  sig'  :  Sig. 

13.  If  decs  h  sbnds  :  sdecs  then  decs  h  sdecs  ok. 

14.  If  decs  h  mod  :  sig  then  decs  h  sig  :  Sig. 

15.  If  decs  h  exp  4-  con  then  decs  h  exp  :  con.  If  in  addition  decs  h  exp  :  con',  then 

decs  h  exp  4.  con'. 

16.  If  decs  h  mod  i  sig  then  decs  h  mod  :  sig.  If  in  addition  decs  h  mod  :  sig',  then 
decs  h  mod  4-  sig'. 

The  following  lemma  states  that  internal  language  judgments  are  preserved  under  substi¬ 
tution  of  values  for  free  variables  in  a  typing  judgmentFwhere  a  value  is  defined  syntactically 
in  Figure  4  to  be  a  phrase  in  evaluated  form. 

Proposition  2  (Substitution) 

1.  If  decs,  var: class,  decs'  h  coni  =  con2  :  knd  and  decs  h  val  :  class  then 
decs,  {val /var} decs'  \- [val /var} coni  =  {val / var} con^  :  knd. 

2.  If  decs,  var:class,  decs'  h  sigi  =  sig^  '•  Sig  and  decs  h  val  :  class  then 
decs,  {val/ var} decs'  \-{val/var}sigi  =  {val/ var}sig2  '■  Sig. 

3.  If  decs,  var-.class,  decs'  h  sigi  <  sig^  '■  Sig  and  decs  h  val  :  class  then 
decs,  {val /var} decs'  \- {val /var} sigi  ^  {val/var}sig2  ■  Sig. 

4.  If  decs,  var-.class,  decs'  h  exp  :  con  and  decs  h  val  :  class  then 
decs,  {val /var} decs'  h  {val/var}exp  :  {val/var}con. 

5.  If  decs,  var-.class,  decs'  h  mod  :  sig  and  decs  h  val  :  class  then 
decs,  {val /var} decs'  h  {val/var}mod  :  {val/var}sig. 
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6.  If  decs,  var: class,  decs'  h  con  :  knd  and  decs  h  val :  sig'  then 
decs,  {val / var} decs'  h  {val/ var} con  :  knd. 

7.  If  decs,  var-.class,  decs'  h  exp  4-  con  and  decs  h  val :  class  then 
decs,  {val /var} decs'  h  {vallvar}exp  4-  {vallvar}con. 

8.  If  decs,  var-.class,  decs'  h  mod  4.  sig  and  decs  h  val  :  class  then 
decs,  {val /var} decs'  h  {val/var}mod  {  {val/var}sig. 

Proof  (sketch):  [By  induction  on  the  derivation  of  the  first  premises;  due  to  space 
constraints  we  show  only  two  sample  cases] 

•  Case:  The  derivation  ends  with  Typing  Rule  49: 

decs,  var-.class,  decs'  h  exp  :  con2-^con 
decs,  var-.class,  decs'  h  exp'  :  con2 
decs,  var-.class,  decs'  h  exp  exp'  :  con 

and  decs  h  val  :  class.  By  the  inductive  hypothesesT 

decs,  {val / var} decs'  h  {val/var}exp  : 

{{val/var}con2)^{{val/var}con) 


and 


decs,  {val /var} decs'  \-  {val/var}exp'  :  {val / var} con2. 
Therefore  from  Typing  Rule  49rwe  can  conclude 


decs,  {val / var} decs'  h  {expy / var}{exp  exp')  :  con. 


•  Case:  the  derivation  ends  with  Typing  Rule  31: 

decs,  var-.class,  decs'  h  mody  :  [labi:deci,  •  •  • ,  labm'-decm, 

lab:var:knd—con2,  sdecs] 
decs,  var-.class,  decs',  deci,  ■  ■  • ,  decm  h  con  =  con2  '■  knd 
decs,  var-.class,  decs'  h  con  :  knd 

decs,  var-.class,  decs'  h  mody.lab  =  con  :  knd 

and  decs  h  val  :  class.  By  the  using  properties  SFlFand  6  of  the  induction 
hypothesisFand  Typing  Rule  31Fwe  have 

decs,  {val /var} decs'  h  {val/var}modv-lab  =  {val/var}con  :  knd. 


Claim  3  (Decidability) 

All  internal  language  judgments  considered  by  the  elaborator  are  decidable. 
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Proof  (sketch):  Because  all  internal-language  module  expressions  generated  by  the  elab- 
orator  have  most-specific  signaturesFthe  decidability  of  the  static  semantics  can  be  reduced 
in  a  straightforward  fashion  to  the  decidability  of  constructor  equivalence.  Of  the  construc¬ 
tor  equivalence  judgmentsF  Rules  32-45  describe  a  familiar  simply-typed  lambda  calculus 
with  records  and  constants.  Even  allowing  the  use  of  simple  abbreviations  in  the  context 
(Rule  30)  can  be  seen  to  preserve  decidability.  Roughly  speaking  one  can  always  first  “inline” 
the  abbreviations  and  then  test  for  equivalence  as  in  the  previous  case. 

It  is  not  obvious  how  to  extend  the  proof  to  include  Rule  31  in  a  simple  fashion.  Lil- 
libridge  [Lil97]  gives  a  complex  argument  for  the  decidability  of  constructor  equivalence  in 
a  related  system  (without  records  of  constructors).  We  conjecture  an  analogous  argument 
would  apply  for  our  system.  ® 


7.1.2  Dynamic  Semantics 

We  define  two  states  to  be  eguwa/eniFwritten 

(A,  a,  E,  phrase)  =  (A',  a',  E',  phrase'), 

if  the  two  states  are  equal  componentwise  up  to  consistent  renaming  of  the  locations  and 
exception  tags  appearing  in  A  and  normal  renaming  of  bound-variables.  This  is  clearly  an 
equivalence  relation  on  states  which  preserves  the  property  of  being  a  terminal  state. 

Lemma  4  (Determinacy  of  Evaluation) 

The  following  properties  hold: 

1.  If  E  is  terminal  and  S  =  E',  then  E'  is  also  terminal. 

2.  El  and  E  =  E',  then  there  exists  a  state  Ej  =  Ei  such  that  E'  ^  E'^. 

3.  If  El  E',  E2  E'a  and  Ei  ^  E2  then  E'j  ^  E^. 

4.  If  E  Et  and  E  E'  then  E*  ^  SJ. 

A  context  (7  is  a  phrase  with  a  single  ho/eFwritten  [].  We  write  C[phrase]  for  the  result 
of  filling  the  hole  in  C  with  phraseT possibly  incurring  variable  capture^  Attack  of  frames 
E  determines  a  context  E  in  the  obvious  way:  []  is  the  context  []Fand  E  o  F  is  the  context 
E[F]. 

Proposition  5  (Decomposition  Replacement) 

1.  If  decs  h  E[exp]  :  con  and  exp  is  closed,  then  decs  h  exp  :  con'  for  some  type  con'. 

Furthermore,  if  decs  h  exp'  :  con'  where  exp'  is  closed,  then  decs  h  E[exp']  :  con. 

2.  If  decs  h  E[mod]  :  con  and  mod  is  closed,  then  decs  h  mod  :  sig  for  seme  signature 
sig.  Furthermore,  if  decs  h  mod'  :  sig  where  mod'  is  closed,  then  decs  h  E[mod']  :  con. 

3.  If  decs  h  E[con']  :  con  and  con'  is  closed,  then  decs  h  con  :  knd  for  some  kind  knd. 
Furthermore,  if  decs  h  con"  :  knd  where  con"  is  closed,  then  decs  h  E[con"]  :  con. 
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Proof  (sketch):  [By  induction  on  E] 

If  £'  =  []  then  the  proposition  is  trivialF  since  E[phrase]  =  phrase.  HenceF  assume 
E  =  E'  o  F.  Due  to  space  constraintsFwe  show  just  one  typical  case. 

•  Case:  F  =  []  exp2.  Then  E[exp]  —  E'[exp  exp2\.  By  the  inductive  hypothesisFwe  have 
decs  h  exp  exp 2  :  con'  for  some  con'.  Inspection  of  the  typing  rules  shows  that  this 
derivation  must  contain  an  application  of  Rule  49  or  Rule  50;  we  show  here  only  the 
former  caseFthe  other  is  similar.  By  inversion  decs  h  exp  :  con2-^con'  and  decs  h 
exp2  :  con2  for  some  type  con2.  FurthermoreFif  decs  h  exp'  :  con2-^con'  then  decs  h 
exp'  exp  :  con'  and  by  the  inductive  hypothesis  we  have  decs  h  E'[exp'  exp2]  :  con;  that 
isF decs  h  E[exp']  :  con. 


7.1.3  Soundness  of  the  Internal  Language 

Following  Harper  [Har93]Fwe  say  that  a  store  a  is  well-formed  with  respect  to  a  context  AF 
written  A  h  crFif 


V/oc  G  BV(A),  if  A  h  loc  :  con  Ref  then  A  h  a{x)  :  con. 

This  formulation  of  store  typing  avoids  the  need  for  complex  maximal  fixed  point  construc¬ 
tions  [Tof90].  (An  essentially  similar  observation  was  made  by  Wright  and  Felleisen  [WF91].) 

Fix  a  base  type  ans  of  answers  to  which  a  completeF closed  program  might  evaluate.^ 
We  can  say  that  a  machine  state  is  well-formedFwritten 

h  (A,  a,  E,  phrase), 

if  and  only  if  A  h  E[phrase]  :  ansTphrase  is  closedFand  Aha.  An  important  property  of 
the  internal  language  semantics  is  that  well-formedness  of  a  state  is  preserved  by  evaluation. 

Proposition  6  (Preservation) 

Jfh  {A,  a,  E,  phrase)  and 


(A,  a,  E,  phrase)  ^  (A',  a',  E',  phrase') 


then  h  {A',  a',  E',  phrase'). 

Proof  (sketch): 

If  the  transition  is  a  search  rule  then  preservation  follows  triviallyFfor  A  =  A'Fa  =  a'Fand 
E[phrase]  =  E'[phrase'].  Hence  we  need  only  consider  the  reduction  rules.  We  show  only 
one  sample  case  here. 

reasonable  choice  might  be  String,  or  Unit  if  we  model  all  I/O  by  updating  the  store;  the  particular 
choice  does  not  affect  our  results. 
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•  Case:  Transition  Rule  160: 

(A,  a,E  o  (TViab  0),  {rbndsy,  lab^exp^,  rbnds^'})  <-> 

(A,  a,  E,  expy) 

Then  E  [])[{rbndsy,  lab^expy,  rbndsy}]  =  E[Kiai,  {rbndsy,  lab=expy,  rbndsy'}]. 

By  the  well-formedness  assumption  and  DecompositionF 

decs  h  TTiab  {rbndSy,  lab=expy,  rbndsy'}  :  con'  for  some  type  con'.  Since  this  judgement 
must  be  proven  using  Typing  Rules  54  and  SSFby  inversion  we  have  that 
decs  h  expy  :  con'.  Since  expy  is  must  by  closed  by  the  well-formedness  assumption 
and  decs  h  E\expy\  :  ans  by  Replacementhwell-formedness  is  preserved. 


FurthermoreFevaluation  of  a  well-typed  program  can  never  “get  stuck” :  if  a  well-formed 
state  is  not  terminalFthere  is  always  an  applicable  transition  to  another  (well-formed)  state. 
The  proof  relies  on  a  characterization  of  the  shapes  of  closed  values  of  each  type. 

Lemma  7  (Canonical  Forms) 

1.  Assume  A  h  expy'  :  con'  where  expy  is  closed. 

If  con'  is  of  the  form. . . 

coni-^con2 
coni—¥con2 

{labi'.coni.,  ■  ■  ■ ,  labn:con„} 

Ei{iabi)  {lab coni, . . . ,  labn^con^f) 

(ttj  (/i  con))  con' 

Tagged 
con  Ref 
base  type 

2.  Assume  A  h  modf  :  sig'  where  modf  is  closed. 

If  sig'  is  of  the  form. . .  then  mody'  is  of  the  form. . . 

[sdecs]  [sbndsy] 

var:sig^sig'  Xvar:sig  .mod 

var:sig—^sig'  Xvarisig.mod 

Proof:  By  inspection  of  the  applicable  typing  rules  for  values.  For  exampleF consider  the 
case  in  which  A  h  expy  :  con'  where  con'  is  a  record  type.  There  are  numerous  rules  that 
allow  the  conclusion  that  an  expression  has  a  record  type  (applicationF record  projectionF 
etc.)  but  only  one — the  rule  for  record  expressions — applies  in  the  case  of  a  closed  value. 
This  is  the  only  possible  form  for  expy.  The  other  cases  are  analogous.  ■ 


then  expy  is  of  the  form. . . 

TTj  fix /6nds  end 
tty  fix /fend  end 

r  ^labi — expyi,  *  *  *  5  labji  expy^^ 
\  fix /fends  end 

•  •JXlabn-^conii...ilabn^conn) 
rol|{’^*  (M  con))  con' 

tzg{tag,  expy) 

loc 

scon 
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Proposition  8  (Progress) 

If  h  E  then  either  E  is  terminal  or  there  exists  a  state  E'  such  that  E  E'. 

Proof  (sketch): 

There  are  three  cases; 

1.  E  is  terminal. 

2.  E  =  {A,a,  II,  E,  phrase)  where  phrase  is  not  a  value.  By  inspectionFfor  every  possible 
phrase  syntax  there  is  an  applicable  rule  in  the  dynamic  semantics  (a  reduction  rule 
for  new_tag[ con]  and  search  rules  otherwise). 

3.  E  =  (A,  a,p,,Eo  F,  val).  This  has  one  subcase  for  each  possible  frame  F.  We  show 
one  such  case: 

•  Case:  F  =  (get]]).  By  well-formedness  and  DecompositionFA  h  get  val  :  con'  for 
some  type  con'.  By  inversion  of  Rule  59  we  have  that  A  h  val  :  con'  Ref.  By 
Canonical  FormsFuo/  is  a  locationFand  by  well-formedness  val  G  BV(cr). 
ThereforeFTransition  Rule  163  applies. 


7.2  Properties  of  the  Elaborator 

The  minimal  requirement  for  the  elaborator  is  that  the  elaboration  of  EL  code  yields  well- 
formed  IL  code: 

Proposition  9  (Well-formed  translation) 

Assume  h  F  ok.  Then  the  following  propositions  hold: 

1.  If  F  h  expr  ^  exp  :  con  then  F  h  exp  :  con. 

2.  If  F  h  match  exp  :  con  then  F  h  exp  :  con. 

3.  If  F  h  strdec  sbnds  :  sdecs  then  F  h  sbnds  :  sdecs. 

4.  If  F  h  strexp  ^  mod  :  sig  then  F  h  mod  :  sig. 

5.  If  F  h  strbind  sbnds  :  sdecs  then  F  h  sbnds  :  sdecs. 

6.  If  F  h  funbind  sbnds  :  sdecs  then  F  h  sbnds  :  sdecs. 

7.  If  F  h  spec  sdecs  then  F  h  sdecs  ok. 

8.  If  F  h  sigexp  sig  :  Sig  then  F  h  sig  :  Sig. 

9.  IfFhty'-^  con  :  Q  then  F  h  con  :  Fl. 

10.  If  F  h  tybind  ^  sbnds  :  sdecs  then  F  h  sbnds  :  sdecs. 
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11.  If  r  h  typdesc  ^  sbnds  :  sdecs  then  F  h  sbnds  :  sdecs. 

12.  If  r  h  etypdesc  ^  sbnds  :  sdecs  then  F  h  sbnds  :  sdecs. 

13.  If  F  h  datbind  sbnds  :  sdecs  then  F  h  sbnds  :  sdecs. 

14.  If  decs  Ijnst'^  'mod  :  sig  then  decs  h  mod  :  sig.  Furthermore,  mod  is  a  syntactic  value 
and  sig  is  the  most-specific  signature  of  mod. 

15.  If  decs  hiq  con  exp  then  decs  h  exp  :  conxcon^Bool.  Furthermore,  exp  is 
a  syntactic  value.  If  decs  A{vari, . . .  ,varn)-con  mod  then  decs  h  mod  : 

,  t)ar^®'*^".conx con— ^Bool. 

16.  If  F  h  pat  ^  exp  :  con  else  sbnds  sdecs  F  h  exp  :  Tagged  and  T  h  exp  :  con,  then 
F  h  sbnds  :  sdecs. 

17.  If  decs-,  path: sig Q  liub  sdec  sbnd  :  sdec'  then  decs  h  path  :  sig^,  decs  h  sdec  ok,  and 
decs  h  sbnd  :  sdec'. 

18.  If  decs  kub  path  :  sigQ  :<  sig  mod  :  sig'  then  decs  h  path  :  sigQ,  decs  h  sigQ  <  sig  :  Sig, 
decs  h  mod  :  sig',  and  decs  h  sig'  <  sig  :  Sig. 

19.  If  F  f^tx  labs  path  :  class  then  F  F  path  :  class.  Furthermore,  F  h  path  :  class'  if  and 
only  if  F  F^tx  labs  ^  path  :  class. 

20.  If  V]  path:sig  liig  labs  ^  labs  :  class  then  F  h  path.labs  :  class.  Furthermore,  if 
F  h  path.labs  :  class'  then  V-,path-.sig  Fig  labs  labs  :  class' . 

21.  If  sig  Fvt  labs  -.=  con  :  knd  ^  sig' :  Sig,  T\-  sig  :  Sig,  and  F  h  con  :  knd,  then  F  h  sig' : 
Sig. 

22.  If  sig  Fh  labs  :=  labs'  :  knd  ^  sig' :  Sig  and  T  \-  sig  :  Sig  then  F  F  sig'  :  Sig. 

Proof:  This  follows  by  induction  on  the  derivation  of  the  first  premises.  B 


To  claim  that  we  have  defined  a  languageFwe  need  elaboration  to  be  a  “function”  in  the 
sense  that  all  possible  elaborations  of  an  EL  program  yield  “equivalent”  IL  programs.  We 
argue  that  such  coherence  is  plausibleFalso  we  have  not  attempted  a  formal  proof. 


Claim  10  (Coherence) 

If 

hasis*>basis:sig i,asis  ^  ^^P  ' 


and 

and 


hasis*>basis:sigi,asis  F  expr  exp'  :  ans 


(•,  •,  let  basis— mod  basis  in  oxp  end)  S( 

then  for  some  terminal  state  EJ  =  St, 

(■,  •,  let  basis=mod basis  in  exp'  end)  M-*  S(. 
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Proof  (sketch):  We  enumerate  the  instances  of  non-determinism  in  the  elaboratorPand 
argue  that  these  should  not  cause  incoherence. 

1.  The  elaborator  may  “guess”  types  for  bound  variables  (in  fn  expressions)  and  when 
instantiating  polymorphism.  Types  in  “dead”  code  may  be  underconstrainedFas  in 

(fn  X  =>  3) (fn  y  =>  y) 

where  there  are  infinitely  many  choices  for  the  type  of  the  identity  fn  y  =>  y.  How- 
everFthe  dynamic  semantics  is  sufficiently  abstract  that  choices  of  types  do  not  affect 
the  course  of  evaluation. 

2.  SimilarlyFthe  elaborator  may  have  a  choice  regarding  how  to  resolve  overloading.  The 
simplest  argument  is  that  each  overloaded  operator  corresponds  to  a  single  operator  in 
the  dynamic  semanticsFso  that  again  evaluation  does  not  depend  on  the  resolved  type. 
(A  more  sophisticated  argument  should  be  able  to  show  that  in  a  complete  programF 
whenever  there  is  a  choice  of  how  to  resolve  overloadingF the  operator  will  never  be 
applied.) 

3.  The  elaborator  must  decide  whether  valuable  expressions  should  be  monomorphic  or 
polymorphicFand  in  the  latter  caseFon  how  many  type  variables  to  generalize.  This 
turns  expressions  into  functor  abstractionsF  which  in  general  causes  incoherence  by 
changing  the  order  of  evaluation — an  expression  wrapped  by  a  functor  will  not  be 
evaluated  until  the  functor  is  applied.  HoweverFwe  only  generalize  valuable  expressionsF 
which  have  no  effectsFso  that  these  choices  will  not  affect  observable  behavior. 

4.  There  is  nondeterminism  in  the  creation  of  equality  functions:  there  may  be  differ¬ 
ent  definitions  of  equality  at  the  same  type.  HoweverFwe  maintain  the  invariant  that 
equality  functions  always  perform  structural  equality  on  the  underlying  values  regard¬ 
less  of  abstraction.  Any  two  candidate  definitions  then  have  the  same  behaviorFand 
no  incoherence  can  arise. 
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